Nous construisons des sites et des applications web en React et Next.js — rendus côté serveur, mesurés à l'aune des Core Web Vitals, et structurés pour que Google indexe chacune des pages qui comptent pour vous.
Une grande partie des sites qu'on nous demande de sauver partagent la même cause racine : ils ont été construits comme une application JavaScript monopage. Le serveur renvoie un document HTML presque vide et le contenu n'apparaît qu'une fois le bundle téléchargé et exécuté par le navigateur. La page paraît impeccable à celui qui l'a commandée. Pour un robot d'exploration au premier passage, c'est une page blanche avec un indicateur de chargement.
Le second schéma est plus subtil. Le site est bien rendu côté serveur, mais toutes les routes partagent un même titre et une même description, il n'existe aucun maillage interne au-delà de la navigation principale, et toute l'activité est comprimée dans une unique page d'accueil défilante. Google ne dispose que d'un seul document : le site ne peut donc concourir que sur une seule requête — face à des organisations qui affichent des centaines de pages indexées.
Ces deux problèmes sont architecturaux. Aucune retouche de mots-clés n'en résout un seul, et c'est pourquoi des sites dans cet état peuvent stagner des années pendant que leur propriétaire réécrit inlassablement ses méta-descriptions.
Les pages sont rendues en HTML sur le serveur et générées statiquement partout où le contenu le permet. La première réponse contient déjà vos titres, vos textes et vos données structurées : un robot n'a pas besoin d'exécuter du JavaScript pour comprendre la page — et un visiteur en connexion lente voit du contenu plutôt qu'un écran de chargement.
Chaque service, localité, article et étude de cas dispose de sa propre route, de son propre titre, de sa propre description et de sa place dans le maillage interne. C'est le levier le plus puissant sur le nombre de requêtes auxquelles un site peut répondre, et il se décide au moment de l'architecture, pas après coup.
Nous fixons un budget pour le Largest Contentful Paint, l'Interaction to Next Paint et le Cumulative Layout Shift pendant le développement, au lieu de profiler après la mise en ligne. Concrètement : des images aux dimensions explicites, des polices auto-hébergées et préchargées, et du JavaScript client ajouté délibérément plutôt que par défaut.
Schémas Organization, Breadcrumb, Service, Article et FAQ, générés à partir du contenu que la page affiche. Parce qu'ils sont dérivés et non rédigés à la main, ils ne peuvent pas diverger de ce que voit réellement le visiteur — condition exigée par Google pour les résultats enrichis.
Le contenu vit dans une couche de données typée ou dans un CMS headless, pas en dur dans les composants. Ajouter une page de service ou publier un article ne mobilise pas un développeur, et les gabarits garantissent que la nouvelle page arrive avec les métadonnées et le schéma déjà corrects.
Vous recevez le code, la configuration de déploiement et la documentation. L'hébergement est le vôtre. Nous n'avons aucun intérêt à retenir un client par une infrastructure qu'il ne peut pas quitter.
Nous choisissons parmi celles-ci selon les besoins du projet et selon ce que votre équipe saura maintenir après la livraison — et non selon nos préférences. Lorsqu'une pile technique est déjà en place et saine, nous travaillons avec elle.
Lorsque le référencement naturel est un véritable canal d'acquisition et non une case à cocher, l'architecture de l'information compte davantage que le design. Nous planifions la structure des URL et le maillage interne avant tout travail d'interface.
Migrations où le site existant est une application monopage rendue côté client, ou rapide en laboratoire et lent pour les vrais utilisateurs. Nous cartographions chaque URL existante vers celle qui la remplace et maintenons les redirections 301 pour préserver le capital de référencement accumulé.
Tableaux de bord, portails et systèmes de réservation où l'application authentifiée cohabite avec un site vitrine qui doit rester explorable. Les deux ont des exigences de rendu opposées et gagnent à être traités comme tels.
Des sites servant plusieurs pays, où chaque langue a besoin de sa propre URL indexable et d'un jeu hreflang correct. Servir quatre langues depuis une seule URL selon les en-têtes du navigateur est une erreur courante et coûteuse — un robot n'envoie jamais qu'une seule langue.
Un site vitrine ciblé, au périmètre de pages défini, demande généralement 4 à 8 semaines à partir du lancement. Les applications web avec authentification, intégrations ou processus métier spécifiques prennent plutôt 8 à 16 semaines. Nous découpons en phases et donnons un prix ferme par phase plutôt qu'un forfait horaire ouvert.
Nous pouvons réunir les conditions qui rendent le positionnement possible : pages indexables, architecture propre, chargement rapide, données structurées exactes et maillage interne cohérent. Nous ne pouvons pas promettre des positions, et vous devriez vous méfier de quiconque le fait. Le classement dépend de la concurrence, de l'autorité de votre site et des systèmes propres à Google, dont aucune agence n'a le contrôle. Ce que nous pouvons garantir, c'est qu'aucun élément technique du site ne le freinera.
Oui. Une bonne part de notre travail consiste à reprendre des projets développés par d'autres. Nous commençons par un audit court, qui vous donne une lecture honnête : le code existant mérite-t-il d'être étendu, ou une reconstruction revient-elle moins cher sur tout horizon réaliste ?
À vous, dès le premier commit. Nous développons dans votre dépôt lorsque vous en avez un, ou nous livrons un dépôt complet accompagné de sa documentation de déploiement à la fin de la mission.
Régulièrement. Cela peut vouloir dire prendre en charge une partie définie du système, faire de la revue de code, ou nous intégrer à votre équipe pour une période. Nous adoptons vos conventions et votre modèle de branches plutôt que d'imposer les nôtres.
Envoyez-nous le problème et les contraintes que vous connaissez déjà. Nous reviendrons vers vous avec ce que nous pensons qu'il exige, une approche et un ordre de grandeur réaliste — ou pour vous dire que ce n'est pas un travail pour lequel nous sommes les bons.
Quand un logiciel du commerce impose des contournements à vos équipes, la facture se paie chaque jour en travail manuel. Nous construisons des systèmes qui épousent le processus que vous avez déjà.
Nous concevons et construisons la partie du produit que personne ne voit jusqu'à ce qu'elle casse : les API, les modèles de données, l'authentification et les intégrations qui tiennent une entreprise ensemble.
Nous concevons des interfaces à partir de preuves : ce que les gens cherchent à faire, là où ils échouent aujourd'hui, et ce que la réalisation peut raisonnablement porter.
