Réponse directe : le premier point de rupture n’est presque jamais le modèle de langage, c’est l’intégration avec le système d’information existant. Un agent IA qui fonctionne parfaitement sur un jeu de données propre échoue en production parce qu’il rencontre une API qui a changé de format, un jeton d’authentification expiré ou une base de données moins cohérente que prévu. Le reste de cet article détaille, dans l’ordre où ils surviennent, les cinq points de rupture que nous observons le plus souvent en mission, et la checklist qui permet de les anticiper avant la mise en production.

Un agent qui a passé tous les tests internes avec un score très élevé peut perdre une part significative de sa fiabilité dans les premières semaines de production, simplement parce que l’environnement réel n’a jamais la propreté d’un environnement de test. Ce n’est pas un défaut d’intelligence du modèle : c’est un défaut d’ingénierie autour du modèle.

Les cinq points de rupture, dans l’ordre où ils arrivent

Chaque point de rupture en entraîne souvent un autre. Les distinguer permet de savoir où investiguer en premier quand un agent commence à se comporter de façon inattendue.

1. L’intégration avec le système d’information

La majorité de la valeur d’un agent vient de sa capacité à agir sur de vrais systèmes : CRM, messagerie, ERP, base de tickets. Ce sont aussi les composants les moins testés, parce qu’ils sont construits en dernier. En production, une API change de format de réponse sans préavis, un jeton expire un dimanche soir, une limite de débit se déclenche pendant un pic d’activité. Chaque intégration ajoute un mode de défaillance à la chaîne complète. Selon une enquête relayée par Smartpoint en 2026, l’intégration au système d’information reste citée par 46% des entreprises comme premier obstacle à la mise en production, devant les coûts (43%) et la qualité de la donnée (42%).

2. La qualité et la fraîcheur des données

Un agent connecté à une base de connaissance obsolète répond avec assurance à partir d’informations fausses. C’est le mode de défaillance le plus dangereux parce qu’il ne provoque aucune erreur technique visible : l’agent continue de répondre, simplement avec des informations périmées ou incomplètes. Une recherche hybride, lexicale et vectorielle, limite le problème mais ne le supprime jamais complètement si la source elle-même n’est pas tenue à jour. Pour une PME, le piège classique consiste à indexer une documentation figée au lancement du projet, puis à oublier de la resynchroniser une fois l’agent en production : au bout de quelques mois, l’agent répond avec assurance sur des tarifs, des délais ou des procédures qui ont changé entre-temps.

3. La fenêtre de contexte qui déborde

Un agent construit sur le motif ReAct enchaîne souvent cinq à quinze cycles avant de livrer un résultat, chacun ajoutant du texte à la fenêtre de contexte. Passé un certain volume, le modèle perd la trace des instructions données en début de conversation, un phénomène documenté sous le nom de « perdu au milieu ». La solution ne consiste pas à agrandir la fenêtre de contexte, mais à réduire ce qu’on y injecte : pertinence en amont plutôt que volume. Résumer les échanges anciens plutôt que les conserver verbatim, et ne rappeler que les faits utiles à l’étape en cours, évite l’essentiel des dérives observées sur les conversations longues.

4. L’absence de garde-fous d’exécution

Sans file d’attente, un agent s’effondre au premier pic de charge. Sans stratégie de nouvelle tentative, il abandonne sur une erreur transitoire qui se serait résolue d’elle-même trente secondes plus tard. Sans contrôle des coûts, une boucle mal bornée peut multiplier les appels au modèle et produire une facture inattendue en quelques heures. File d’attente, nouvelle tentative, budget : ces trois garde-fous sont les premiers éléments d’infrastructure à manquer dans un prototype qui n’a jamais connu la production. Ils sont aussi les moins visibles lors d’une démonstration commerciale, puisqu’une démo tourne par construction sur un volume faible et un jeu de cas favorable : c’est précisément ce qui les rend faciles à sous-estimer avant le premier vrai pic de trafic.

5. Le vide de gouvernance

Quand un agent se trompe, quelqu’un doit pouvoir expliquer pourquoi et corriger le tir. Sans journal de décision, sans propriétaire clairement identifié côté métier, l’erreur se répète parce que personne n’a le mandat de la corriger. C’est souvent le dernier point de rupture à apparaître, et le plus coûteux à combler après coup, parce qu’il touche à l’organisation plus qu’à la technique. Une équipe qui découvre ce vide après un incident perd un temps précieux à reconstituer, a posteriori, qui aurait dû valider quoi : mieux vaut le trancher avant le premier déploiement que pendant une réunion de crise.

Les métriques qui révèlent une défaillance avant l’utilisateur

Le taux de disponibilité et la latence moyenne, hérités du monitoring applicatif classique, ne suffisent pas à surveiller un agent : un agent peut répondre vite, sans erreur serveur, et pourtant produire un résultat faux ou une action incorrecte. Quatre indicateurs complémentaires comptent davantage. Le taux d’échec par appel d’outil, mesuré séparément de la disponibilité générale, révèle les intégrations qui se dégradent avant qu’un utilisateur ne s’en plaigne. Le taux de nouvelle tentative anormale signale une boucle qui commence à mal se comporter. Le coût par tâche réussie, plutôt que le coût total, permet de repérer une dérive avant qu’elle ne se voie sur la facture mensuelle. Enfin, un échantillon de réponses relu manuellement chaque semaine, même petit, reste la seule méthode fiable pour détecter une dérive de justesse que les métriques techniques ne captent jamais seules.

Symptôme, cause racine, correction

Ce tableau reprend les symptômes les plus fréquents observés en mission et la correction qui règle généralement le problème à la racine, plutôt qu’en surface.

La checklist avant la mise en production

Aucune de ces étapes ne demande une grande équipe ou un long délai. La plupart se mettent en place en un jour ou deux, et chacune supprime une catégorie entière des défaillances décrites plus haut. Dans l’ordre, les étapes qui réduisent le plus le risque de défaillance en production.

1. Délimiter un périmètre étroit, avec des entrées et des sorties claires, plutôt qu’une tâche ouverte.
2. Tester sur un échantillon de données réelles, pas uniquement sur un jeu synthétique propre.
3. Mettre en place une file d’attente et un traitement asynchrone avant le premier pic de charge, pas après.
4. Définir une stratégie de nouvelle tentative qui distingue les erreurs récupérables des erreurs définitives.
5. Fixer des quotas de tokens et des coupe-circuits automatiques par utilisateur ou par tâche.
6. Journaliser chaque décision et chaque appel d’outil, pas seulement les erreurs.
7. Désigner un responsable métier de l’agent, distinct de l’équipe qui l’a construit.
8. Prévoir une procédure de retour à un traitement manuel si l’agent sort de son périmètre.

Quand un agent IA n’est pas le bon choix

Un agent apporte de la valeur quand la tâche varie assez pour justifier un raisonnement, mais reste assez cadrée pour être vérifiée. En dehors de cette zone, ce n’est généralement pas le bon outil. Une tâche répétitive avec des règles fixes et un faible volume se résout mieux avec une automatisation classique, moins chère à construire et plus simple à auditer. À l’inverse, une décision à fort enjeu, difficile à vérifier après coup, ou soumise à une obligation de traçabilité stricte, garde un humain dans la boucle plus longtemps que ne le suggèrent les démonstrations commerciales. Pour une fiduciaire ou un cabinet privé, cela veut dire, concrètement : automatiser le tri et la préparation d’un dossier, mais laisser la validation finale à une personne identifiée, plutôt que de déléguer la décision elle-même à l’agent. Le signal le plus fiable : si personne dans l’organisation ne peut expliquer une décision automatisée a posteriori, l’agent n’est pas prêt pour ce périmètre, quel que soit son score sur un banc d’essai.

Ce que nous observons en mission

Chez Tesseract Studio, quatre produits tournent aujourd’hui en production, livrés par des ingénieurs qui travaillent en immersion chez le client plutôt qu’à distance sur un cahier des charges figé, l’approche que nous détaillons dans notre article sur le Forward Deployed Engineer. Le constat est constant d’une mission à l’autre : les points de rupture ne sont presque jamais dans le modèle choisi, mais dans l’ingénierie qui l’entoure, files d’attente, journalisation, propriété métier. C’est aussi ce qui distingue un prototype convaincant en démonstration d’un système qui tient sa charge un an plus tard. Traiter ces cinq points de rupture comme des risques de projet, au même titre qu’un budget ou un délai, plutôt que comme des détails techniques à régler après coup, change directement la probabilité que l’agent tienne au-delà des premières semaines. Vous pouvez consulter le détail de nos réalisations ou parcourir tous nos articles sur le sujet.

Un robot d’entraînement lit une page pour l’ajouter à la base de données qui servira à construire un futur modèle. Un robot de réponse lit une page au moment précis où un utilisateur pose une question, pour extraire une citation ou un lien dans la réponse générée. Techniquement, les deux s’annoncent de la même façon dans un fichier robots.txt, avec une ligne User-agent. Économiquement, ils n’ont rien à voir : bloquer l’un protège un contenu contre une réutilisation future, bloquer l’autre retire immédiatement votre site des réponses citées par ChatGPT, Claude ou Perplexity. La confusion entre les deux est la première erreur que commettent les PME romandes lorsqu’elles configurent leur fichier robots.txt.

Depuis l’ouverture massive des assistants de recherche IA au grand public, beaucoup de responsables marketing romands se posent la question dans l’urgence, souvent après avoir lu un article alarmiste sur le pillage de contenu par les modèles de langage. La réaction réflexe consiste à bloquer tout ce qui ressemble à un robot IA dans le fichier robots.txt. Cette réaction protège effectivement un contenu contre l’entraînement futur d’un modèle, mais elle retire aussi, dans le même geste, toute chance d’apparaître dans une réponse ChatGPT, Claude ou Perplexity le jour même. Le reste de cet article détaille le calcul, robot par robot, pour éviter de trancher les deux questions en même temps sans le vouloir.

GPTBot, ClaudeBot, PerplexityBot : qui fait quoi

Chaque opérateur publie en réalité plusieurs robots, avec des fonctions distinctes. Les confondre revient à bloquer sa visibilité dans les réponses IA en croyant seulement limiter l’entraînement.

Une confusion fréquente mérite d’être signalée à part : Google-Extended n’est pas Googlebot. Bloquer Google-Extended n’a aucun effet sur l’indexation classique d’un site dans Google Recherche, qui reste entièrement pilotée par Googlebot. Un responsable marketing qui bloque Google-Extended pensant protéger son référencement classique ne change rien à son classement, mais réduit sa présence potentielle dans les résumés générés par l’intelligence artificielle de Google.

Une analyse du réseau Cloudflare publiée en août 2026 montre que GPTBot est bloqué 2,33 fois pour chaque site qui l’autorise, alors qu’OAI-SearchBot, le robot de recherche de la même entreprise, est autorisé presque aussi souvent qu’il est bloqué. Les éditeurs qui ont pris le temps de distinguer les deux robots ne subissent donc pas le même arbitrage que ceux qui bloquent « OpenAI » en bloc.

Pour une fiduciaire genevoise ou un cabinet d’architectes vaudois, la différence se traduit très concrètement. Un client potentiel demande à ChatGPT une recommandation de fiduciaire à Genève : si GPTBot est bloqué mais qu’OAI-SearchBot est autorisé, la page reste éligible à cette réponse. Si les deux sont bloqués sous une même règle générique, la fiduciaire disparaît purement et simplement de cette conversation, sans que personne dans l’entreprise ne s’en rende compte, faute d’outil de suivi dédié aux citations IA.

Le vrai calcul : ce qu’un blocage protège, ce qu’il coûte

Ce qu’un blocage protège réellement

Bloquer un robot d’entraînement limite la réutilisation de vos textes dans un futur modèle de langage. C’est pertinent pour un contenu à forte valeur ajoutée éditoriale, un jeu de données propriétaire, ou un secteur où la confidentialité contractuelle interdit toute réutilisation externe. Ce blocage n’a en revanche aucun effet rétroactif : un contenu déjà indexé par un robot d’entraînement avant le blocage reste dans les jeux de données déjà constitués.

Ce qu’un blocage coûte en visibilité IA

Bloquer un robot de réponse, souvent par excès de prudence en bloquant tous les user-agents contenant « GPT » ou « AI », retire mécaniquement votre site des réponses citées. Pour une PME dont l’objectif affiché est justement d’être trouvée par les moteurs de réponse, ce choix contredit l’objectif business. C’est un passage autonome qui résume le sujet : un robot d’entraînement construit un modèle, un robot de réponse construit une citation ; le premier se bloque pour protéger un contenu, le second se bloque au prix de la visibilité qu’on cherche à obtenir.

La méthode en cinq étapes

1. Clarifier l’objectif : protéger un contenu propriétaire, viser des citations dans les réponses IA, ou les deux selon les sections du site.
2. Séparer, pour chaque opérateur, le robot d’entraînement du robot de réponse, plutôt que de bloquer un opérateur en bloc.
3. Écrire une ligne User-agent explicite par robot dans robots.txt, jamais une règle générique visant tout ce qui contient « bot » ou « AI ».
4. Vérifier dans les journaux du serveur que les robots respectent effectivement les directives publiées, plutôt que de se fier au seul fichier.
5. Revoir la configuration chaque trimestre : les opérateurs ajoutent régulièrement de nouveaux user-agents, avec des fonctions différentes.

Configuration robots.txt : un exemple concret

Voici une configuration qui autorise les robots de réponse tout en bloquant les robots d’entraînement, adaptée à une PME qui vise la visibilité dans les réponses IA sans céder l’intégralité de son contenu à l’entraînement de modèles tiers :

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-User
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Disallow: /

Cette configuration illustre un arbitrage précis, pas une recommandation universelle : une PME qui vend un contenu à forte valeur documentaire peut préférer bloquer aussi les robots de réponse ; un média qui vit du trafic direct peut préférer tout autoriser.

Vérifier que vos directives sont respectées

Les grands opérateurs déclarent publiquement respecter le fichier robots.txt pour leurs robots nommés, mais rien n’empêche une erreur de configuration côté site ou un robot tiers qui usurpe un user-agent connu. Deux vérifications suffisent la plupart du temps : consulter les journaux d’accès du serveur pour confirmer que les IP correspondent aux plages publiées par l’opérateur, et tester la page avec l’outil d’inspection d’URL de Google Search Console pour confirmer qu’aucune règle involontaire ne bloque un robot légitime.

Un troisième contrôle, plus rarement pratiqué, consiste à interroger directement les moteurs de réponse sur son propre secteur, avec un petit jeu de questions représentatif (« quelle fiduciaire recommander à Genève », « quel cabinet d’architectes travaille en Suisse romande »), et à noter si le site apparaît. C’est la seule vérification qui mesure l’effet réel du calcul robots.txt plutôt que sa seule conformité déclarative. Un tableau de suivi mensuel, même sommaire, suffit à repérer une régression après un changement de configuration.

Quand ce calcul fin n’est pas le bon choix

La distinction robot par robot suppose du temps de maintenance et une veille sur les user-agents publiés par chaque opérateur. Deux cas justifient une approche plus radicale. D’abord, un site qui traite des données sous obligation de confidentialité contractuelle ou réglementaire (santé, finance, données clients) : bloquer tous les robots IA sans distinction reste la position la plus sûre, même au prix d’une invisibilité totale dans les réponses IA. Ensuite, un site éditorial qui vit du volume de citations et n’a aucun contenu sensible : tout autoriser, sans se soucier de la distinction entraînement/réponse, évite une maintenance disproportionnée par rapport à l’enjeu. Entre ces deux extrêmes, la majorité des PME romandes a intérêt au calcul fin décrit ici : ni le blocage réflexe qui sacrifie la visibilité IA sans bénéfice mesurable, ni l’ouverture totale qui cède un contenu propriétaire sans contrepartie.

Un dernier facteur pèse dans la décision : la taille de l’équipe qui maintiendra la configuration dans la durée. Une PME sans responsable technique dédié a plus intérêt à une règle simple, révisée une fois par an avec l’aide d’un prestataire, qu’à une matrice de dix robots mise à jour au fil de l’actualité. Le calcul fin décrit dans cet article reste un outil, pas une obligation : mieux vaut une configuration simple appliquée correctement qu’une configuration précise jamais tenue à jour.

La configuration du robots.txt reste un réglage technique parmi d’autres : elle ne remplace pas le travail de fond sur la structure des pages et les données vérifiables détaillé dans notre panorama des six leviers de la visibilité dans les moteurs de réponse IA. Le fichier robots.txt et le llms.txt répondent à deux questions différentes : le premier autorise ou bloque l’accès, le second résume le contenu pour les robots déjà autorisés à passer. Pour une PME qui veut savoir où elle se situe avant d’ajuster ses directives, le Sprint GEO part d’un audit concret. L’ensemble des articles du studio sur le sujet reste consultable sur le blog.

Réponse directe : un llms.txt est un résumé texte de votre entreprise, publié à la racine de votre site, écrit pour un assistant IA plutôt que pour un visiteur. Il prend une heure à produire, ne coûte rien à héberger, mais ne garantit aucune citation dans ChatGPT ou Perplexity. Le reste de cet article détaille pourquoi, et ce qui compte davantage à sa place.

Un fichier llms.txt est une page texte au format Markdown, publiée à la racine d’un site (exemple.ch/llms.txt), qui résume l’activité d’une entreprise et pointe vers ses pages les plus importantes. Contrairement à une page web classique, il est pensé pour être lu par un assistant IA plutôt que par un navigateur : pas de mise en page, pas de menu, pas de script, seulement du texte structuré en titres et en listes de liens.

L’idée a été proposée en 2024 par le développeur Jeremy Howard. Le constat de départ est simple : un modèle de langage dispose d’une fenêtre de contexte limitée, et un site web moderne contient trop de bruit (navigation, bannières, scripts) pour qu’un assistant en extraie facilement l’essentiel en une seule requête. Le llms.txt propose un raccourci : un résumé en une phrase, puis une liste organisée des pages qui comptent vraiment.

Pourquoi ce format existe

Trois moteurs de réponse dominent aujourd’hui les questions professionnelles : ChatGPT, Perplexity et les AI Overviews de Google. Chacun envoie des robots différents (GPTBot, PerplexityBot, Google Extended) qui explorent le web de façon plus ciblée et plus rapide qu’un moteur de recherche classique. Un llms.txt bien tenu leur donne, en théorie, une carte directe des pages à privilégier plutôt qu’un site entier à parcourir.

C’est une promesse séduisante pour une PME qui n’a ni le temps ni le budget d’une stratégie de contenu massive : un seul fichier, mis à jour en quelques minutes, censé orienter des robots qui ignorent tout du reste du site. Retenez une définition simple, qui tient seule hors contexte : un llms.txt est un résumé d’entreprise écrit pour une machine plutôt que pour un humain, publié à une adresse fixe, que les assistants IA peuvent consulter avant d’explorer le reste du site.

Le format n’a toutefois jamais été adopté officiellement par un moteur de réponse majeur. OpenAI, Anthropic et Google n’ont publié aucune documentation confirmant qu’ils s’appuient dessus pour orienter leurs robots. Il s’agit d’une convention communautaire, portée par des outils tiers (générateurs, validateurs, CMS) davantage que par les entreprises qui exploitent les modèles.

llms.txt, robots.txt et sitemap.xml : trois fichiers, trois rôles

Les trois fichiers se ressemblent (racine du site, format texte) mais répondent à des questions différentes. Les confondre est l’erreur la plus fréquente chez les équipes qui découvrent le sujet.

Un point mérite d’être clarifié tout de suite, car il revient souvent en entretien client : llms.txt ne bloque rien. Pour empêcher un robot d’entraîner un modèle sur vos contenus, c’est robots.txt qu’il faut modifier, avec la directive visant le robot concerné.

Écrire un llms.txt en six étapes

1. Lister les pages qui comptent vraiment. Entre 10 et 30 pages : l’accueil, l’offre, les études de cas, les articles de fond. Pas le mentions légales, pas les pages de tags.
2. Rédiger un résumé d’une phrase. C’est la ligne la plus reprise si un modèle cite le fichier : elle doit tenir seule, hors contexte.
3. Structurer en Markdown. Un titre de niveau 1 avec le nom de l’entreprise, une citation en exergue pour le résumé, puis des sections de niveau 2.
4. Lister les liens au format standard. Un tiret, un lien Markdown, une description courte, sur une seule ligne par page, pour rester facile à analyser par une machine.
5. Publier le fichier à la racine. À l’adresse exacte votredomaine.ch/llms.txt, en URL absolue, jamais dans un sous-dossier.
6. Le tenir à jour à chaque publication. Un fichier qui référence un article supprimé depuis six mois envoie un signal de négligence, pas de sérieux.

Un point technique évite une déconvenue fréquente : le fichier doit rester accessible sans authentification et sans redirection. Un llms.txt servi derrière un mur de cookies, ou redirigé vers une page HTML, n’est tout simplement pas lu.

Vérifier que le fichier est effectivement consulté

Écrire le fichier ne suffit pas à savoir s’il sert à quelque chose. La méthode la plus fiable reste la plus simple : consulter les journaux d’accès du serveur (ou ceux de l’hébergeur, Vercel et Cloudflare les exposent tous les deux) et filtrer les requêtes vers /llms.txt par en-tête User-Agent. Les robots qui s’annoncent honnêtement se identifient clairement : GPTBot, ClaudeBot, PerplexityBot, Google-Extended. Une requête sans en-tête reconnaissable, ou provenant d’une adresse IP résidentielle, est presque toujours un audit humain ou un outil tiers, pas un assistant IA en train de préparer une réponse.

Sur la majorité des sites de PME, ce comptage tient sur une ligne de commande et quelques minutes par mois. C’est un suivi minimal, mais bien plus honnête qu’une simple présomption d’efficacité.

Un exemple réel : le llms.txt de tesseractstudio.ch

Plutôt que de décrire la théorie, voici la pratique. Le llms.txt de ce site tient sur une page : un résumé d’une phrase, trois sections (ce que fait le studio, pourquoi nous, les offres et prix), la liste des réalisations avec des chiffres précis, puis la liste des articles de blog, régénérée automatiquement à chaque publication. Rien de plus. Aucune section décorative, aucun argumentaire commercial étendu : les modèles de langage ne récompensent pas la longueur, ils cherchent la densité factuelle.

La partie blog est générée par le script de build à chaque nouvel article, avec une balise de début et de fin dans le fichier source. C’est un détail technique, mais il illustre le principe central : un llms.txt qui demande une mise à jour manuelle à chaque publication finit par ne plus être mis à jour du tout.

Les erreurs qui rendent un llms.txt inutile

La plus commune consiste à copier le contenu marketing de la page d’accueil, adjectifs compris. Un modèle de langage traite mal les superlatifs ("leader", "meilleur", "innovant") : ils n’apportent aucune information vérifiable. La deuxième erreur est la longueur : un fichier de plusieurs milliers de lignes n’est plus un résumé, il redevient un site à explorer, ce que le format était censé éviter. La troisième est l’abandon : un llms.txt publié une fois puis jamais revu perd toute valeur en quelques mois, à mesure que les pages qu’il liste changent ou disparaissent.

La quatrième erreur, plus discrète, consiste à traiter le llms.txt comme un mécanisme de contrôle d’accès. Ce n’est pas son rôle : un robot qui ignore délibérément les règles (ce qui arrive) n’est freiné ni par llms.txt ni par robots.txt. Les deux fichiers reposent sur la coopération volontaire du robot, pas sur un blocage technique. Pour une restriction réellement contraignante, il faut passer par une règle serveur (pare-feu applicatif, liste d’adresses IP) plutôt que par un fichier texte.

Quand ne pas s’embêter avec un llms.txt

C’est le point que la plupart des guides sur le sujet évitent, et il mérite d’être dit avec des chiffres plutôt que des intuitions. Ahrefs a analysé en mai 2026 les journaux de 137 210 domaines suivis par son outil d’analytics : 97 % des fichiers llms.txt publiés n’ont reçu strictement aucune requête ce mois-là. Sur les quelque 38 000 domaines dotés d’un fichier valide, environ 1 100 seulement ont vu passer un visiteur, humain ou robot. Et parmi les rares requêtes reçues, 77 % ne venaient pas d’un outil IA mais d’audits SEO ou de robots génériques : Slackbot, à lui seul, a sollicité plus de llms.txt que PerplexityBot.

Une étude indépendante d’Otterly.ai, menée sur 90 jours et plus de 62 100 visites de robots IA sur un site test, arrive à la même conclusion : le fichier llms.txt n’a reçu que 84 requêtes, soit trois fois moins qu’une page de contenu moyenne, et aucune corrélation n’a été mesurée entre sa présence et une hausse des citations. Google a d’ailleurs indiqué publiquement ne pas s’appuyer sur ce format.

La conclusion honnête : si produire ce fichier prend une heure et qu’il se met à jour tout seul, le coût d’opportunité est nul et rien n’empêche de le publier, au cas où l’adoption progresse. Mais commander un audit payant ou un projet dédié uniquement pour un llms.txt n’est aujourd’hui pas un investissement défendable. Ce n’est pas là que se joue la visibilité dans les moteurs de réponse.

Le calcul change selon la taille de votre équipe. Si vous avez un développeur capable de générer le fichier à partir du contenu existant, en une heure, vous n’avez aucune raison de vous en priver. Si vous devez faire appel à une agence facturée à la journée pour la même tâche, mieux vaut consacrer ce budget à l’un des six leviers réellement corrélés à des citations mesurables : la structure des pages, les données structurées, ou un contenu qui répond directement à une question sans détour marketing. Le llms.txt est une case à cocher, pas une stratégie.

Ce qui compte davantage pour être cité

Le llms.txt reste une brique parmi d’autres, et une brique mineure. Les leviers qui font réellement une différence mesurable sur la citabilité (structure des pages, densité factuelle, données structurées, rendu côté serveur) sont détaillés dans notre panorama des six leviers de la visibilité dans les moteurs de réponse IA. Pour une PME romande qui veut savoir où elle en est avant d’investir du temps, le Sprint GEO part d’un audit concret plutôt que d’un fichier texte isolé. L’ensemble des articles du studio sur le sujet est regroupé sur le blog.

Le GEO, pour Generative Engine Optimization, est le travail qui consiste à rendre un site exploitable et citable par ces moteurs de réponse. Ce n’est pas un remplacement du SEO : c’est une couche qui s’ajoute, avec ses propres règles et ses propres mesures.

Ce que le GEO change par rapport au SEO

Le SEO optimise pour un classement de pages. Le GEO optimise pour l’extraction d’un passage. La différence est structurante.

Un moteur de recherche renvoie une liste, et l’utilisateur choisit. Un moteur de réponse compose un texte à partir de fragments prélevés dans plusieurs documents, puis cite ses sources. L’unité qui compte n’est donc plus la page, c’est le paragraphe. Un article excellent dont aucun paragraphe ne se suffit à lui-même sera lu par la machine et écarté à la composition.

Trois conséquences concrètes :

• Une position 1 ne garantit plus la citation. Les moteurs de réponse piochent régulièrement en dehors du top 3 quand un passage plus net répond mieux.
• Le trafic peut baisser alors que la visibilité monte. Vous êtes lu, cité, mais l’utilisateur n’a plus besoin de cliquer.
• La marque devient un actif mesurable. Être nommé dans une réponse, même sans lien, oriente la suite de la conversation.

Comment un moteur de réponse choisit ses sources

Les mécanismes exacts ne sont pas publics et varient d’un moteur à l’autre. Trois étapes sont néanmoins communes à toutes les architectures de génération augmentée par la recherche.

1. L’accès

Le moteur doit pouvoir lire la page. Cela suppose que son robot ne soit pas bloqué, que le contenu soit présent dans le HTML servi, et que la page réponde vite. Les robots des moteurs de réponse sont moins patients que Googlebot et n’exécutent pas tous le JavaScript. Un site dont le contenu n’apparaît qu’après hydratation côté client est, pour eux, une page vide.

2. La récupération

La question de l’utilisateur est transformée en une ou plusieurs requêtes, puis des passages sont récupérés depuis un index. À ce stade, ce qui est comparé n’est pas votre page entière mais des fragments. D’où l’importance d’une structure où chaque section traite une question et une seule.

3. La composition

Le modèle rédige la réponse à partir des passages retenus et attribue les citations. Il privilégie les fragments qui répondent directement, qui portent une donnée vérifiable, et qui ne demandent pas de contexte extérieur pour être compris.

Les six leviers qui comptent

Rendre le contenu lisible sans JavaScript

C’est le prérequis, et c’est le point qui disqualifie le plus de sites. Vérifiez ce que voit un robot en récupérant votre page sans exécuter de script. Si le texte n’y est pas, aucun autre travail ne servira.

Écrire des passages autonomes

Chaque paragraphe doit pouvoir être extrait et rester compréhensible seul. Cela veut dire : reprendre le sujet plutôt que d’écrire « il », poser la définition avant de l’utiliser, et placer la réponse dans la première phrase plutôt qu’en conclusion. Un titre de section formulé en question, suivi d’une réponse directe en une ou deux phrases, est le format le plus souvent repris.

Donner des données vérifiables

Les modèles favorisent les fragments qui contiennent un chiffre, une date, un nom, une valeur. « Le délai est court » n’est pas citable. « Le délai est de quatorze jours ouvrables » l’est. Si vous avancez un chiffre, indiquez sa source et sa date : c’est ce qui permet au moteur de le reprendre sans risque.

Structurer les données

Le balisage Schema.org ne fait pas apparaître magiquement votre site dans une réponse, mais il lève les ambiguïtés : qui publie, quand, sur quel sujet, avec quelle expertise. Les types utiles sont peu nombreux : Organization, Article ou BlogPosting, FAQPage, Product, LocalBusiness. Reliez-les entre eux par un identifiant stable plutôt que de redéclarer l’entreprise sur chaque page.

Publier un fichier llms.txt

Le fichier /llms.txt est une proposition de convention, pas un standard imposé, et son adoption reste partielle. Le coût est nul et l’intérêt réel : il donne une description en texte brut de ce que fait l’entreprise, de ses offres et de ses pages importantes. Traitez-le comme une fiche d’identité destinée à une machine.

Décider quels robots vous laissez passer

GPTBot, ClaudeBot, PerplexityBot, Google-Extended : chacun se déclare, et chacun peut être autorisé ou refusé dans robots.txt. Le calcul est simple. Si votre modèle économique repose sur la vente d’audience publicitaire, bloquer se défend. Si vous vendez un service et cherchez des clients, bloquer revient à sortir de l’annuaire. Pour une entreprise de services, laisser passer est presque toujours le bon choix.

Ce qu’il faut mesurer

Le GEO souffre d’un problème de mesure : il n’existe pas d’équivalent de la Search Console pour les moteurs de réponse. Trois indicateurs restent accessibles sans outil payant.

Le premier est le plus utile et le plus laborieux. Il se construit en une heure : trente questions que poserait un client, posées chaque mois, dans un tableau. C’est rudimentaire, et c’est déjà plus que ce que mesure la plupart des entreprises. Si vous préférez le point de départ tout fait, nous le produisons gratuitement : voir nos formules.

Par où commencer

Dans l’ordre, parce que chaque étape conditionne la suivante :

1. Vérifiez que votre contenu est lisible sans JavaScript et que les robots des moteurs de réponse ne sont pas bloqués.
2. Posez vos trente questions et notez qui est cité aujourd’hui. C’est votre point zéro.
3. Reprenez les cinq pages qui portent votre offre, et réécrivez-les en passages autonomes avec des données datées.
4. Ajoutez le balisage structuré et le fichier llms.txt.
5. Reposez les mêmes questions six semaines plus tard.

Rien de tout cela ne demande un profil marketing : ce sont des décisions techniques, prises par la personne qui écrit le code. C’est exactement le rôle d’un Forward Deployed Engineer, qui part du problème plutôt que du ticket.

Ce travail ne demande pas de refonte. Il demande de la précision, et un peu de constance dans la mesure. Sur un produit encore à construire, ces choix se prennent au moment de l’architecture plutôt qu’après coup : c’est ce que nous détaillons dans notre méthode de livraison en quatre-vingt-dix jours.

Les quatre moteurs ne se comportent pas pareil

Parler des « moteurs de réponse » au singulier est commode, mais trompeur. Les quatre principaux ont des architectures différentes, et ce qui fonctionne sur l’un ne se transpose pas mécaniquement.

Conséquence pratique : un travail SEO classique reste indispensable pour les AI Overviews, alors que Perplexity et ChatGPT offrent une porte d’entrée à des sites jeunes ou peu autoritaires, à condition que le contenu soit accessible et net. C’est là que se trouve la fenêtre d’opportunité pour une PME qui démarre.

Cinq erreurs qui coûtent cher

Croire qu’un blocage protège le contenu

Bloquer GPTBot dans robots.txt empêche le crawl, pas la citation. Un moteur peut toujours reprendre votre contenu s’il le trouve ailleurs, repris sur un site tiers, sans le lien vers vous. Vous perdez l’attribution sans gagner la protection.

Confondre le robot de crawl et le robot de réponse

Chez OpenAI, GPTBot alimente l’entraînement, OAI-SearchBot sert la recherche, et ChatGPT-User agit quand un utilisateur demande explicitement de consulter une page. Bloquer le premier en pensant préserver l’entraînement tout en restant visible en recherche est cohérent ; bloquer les trois par précaution vous sort complètement du circuit.

Optimiser la page d’accueil plutôt que les pages de réponse

Les moteurs de réponse citent rarement une page d’accueil, parce qu’elle répond à tout et donc à rien. Ils citent la page qui traite précisément la question posée. Une page par question vaut mieux qu’une page qui les couvre toutes.

Enterrer la réponse sous l’introduction

La structure narrative habituelle, contexte puis développement puis conclusion, est exactement l’inverse de ce qu’il faut. Placez la réponse dans les deux premières phrases de la section, puis développez. Le fragment extrait sera le début, pas la fin.

Publier des chiffres sans date ni source

Un modèle qui doit choisir entre deux affirmations contradictoires privilégie celle qui porte une date et une origine. Un chiffre nu est un chiffre qu’on ne reprendra pas, ou pire, qu’on reprendra en l’attribuant à quelqu’un d’autre.

Construire son jeu de questions

La mesure évoquée plus haut ne vaut que si les questions ressemblent à celles que posent réellement vos clients. Voici la méthode que nous appliquons, en une heure.

1. Dix questions de définition. Ce que votre métier fait, formulé par quelqu’un qui ne connaît pas le vocabulaire du secteur.
2. Dix questions de comparaison. Votre solution face aux alternatives, y compris l’alternative de ne rien faire.
3. Cinq questions de choix. Comment sélectionner un prestataire, sur quels critères, à quel prix.
4. Cinq questions locales. La même chose avec votre ville ou votre canton, si vous avez une clientèle de proximité.

Chaque question est posée aux quatre moteurs, et vous notez trois choses : êtes-vous cité, qui l’est à votre place, et la réponse est-elle exacte. Ce troisième point est souvent le plus instructif : une réponse fausse sur votre entreprise se corrige en publiant la bonne information dans un format extractible, pas en s’en plaignant.

Refaites l’exercice tous les deux mois. Une mesure isolée ne dit rien ; c’est l’écart entre deux mesures qui a du sens.

À retenir

• Le GEO optimise l’extraction d’un passage, là où le SEO optimise le classement d’une page. L’unité qui compte est le paragraphe.
• Un site dont le contenu n’apparaît qu’après exécution du JavaScript est, pour la plupart des robots de moteurs de réponse, une page vide.
• Un fragment contenant un chiffre daté et sourcé est repris plus souvent qu’un fragment qui décrit la même chose avec des adjectifs.
• Il n’existe pas de console officielle pour mesurer sa visibilité dans les IA. La méthode praticable est un jeu fixe de questions posées à intervalle régulier.
• Pour une entreprise de services, bloquer GPTBot ou PerplexityBot revient à sortir de l’annuaire que consultent ses prospects.

Le métier sort aujourd’hui du cercle des éditeurs américains, parce que l’IA a rendu le modèle viable à petite échelle. Voici ce qu’il recouvre concrètement, et quand il est pertinent pour une PME.

Ce que fait un Forward Deployed Engineer

Un FDE est un ingénieur qui écrit du code, mais dont le point de départ est le problème du client plutôt qu’un ticket. Il passe une part importante de son temps à comprendre le métier : comment le travail se fait aujourd’hui, où il coince, quelles données existent réellement et dans quel état.

La séquence habituelle tient en quatre temps :

1. Observer le processus tel qu’il est pratiqué, pas tel qu’il est documenté.
2. Construire une première version étroite qui résout un cas précis.
3. La mettre entre les mains des utilisateurs en quelques jours, pas en quelques mois.
4. Corriger sur la base de l’usage, puis élargir.

Ce qui distingue ce profil n’est pas la compétence technique, c’est le refus de la séparation entre celui qui comprend le problème et celui qui écrit la solution.

La différence avec un consultant et avec une agence

Le consultant produit une analyse que quelqu’un devra exécuter. L’agence exécute une spécification que quelqu’un devra avoir écrite juste. Le FDE supprime l’intermédiaire, et absorbe le risque que la spécification soit fausse, ce qui est le cas le plus fréquent.

Pourquoi le modèle devient accessible maintenant

Historiquement, ce modèle coûtait cher : il fallait un ingénieur senior, sur place, plusieurs mois. Seules les grandes entreprises pouvaient le financer.

Deux choses ont changé.

Le coût de la première version a chuté

Écrire une première version fonctionnelle demandait des semaines. Avec un assistant de code utilisé sérieusement, ce délai se compte désormais en jours pour beaucoup de cas. Cela change la nature de la conversation : on ne discute plus d’une maquette, on regarde un logiciel qui tourne sur les données du client.

Le coût de l’erreur a baissé

Quand une première version coûte trois semaines, on la protège, et on discute pendant des mois avant de l’écrire. Quand elle coûte trois jours, on la jette sans douleur et on recommence. C’est ce déplacement qui rend le modèle itératif économiquement viable pour une PME.

La conséquence est contre-intuitive : l’IA n’a pas rendu le développeur inutile, elle a rendu le développeur présent chez le client abordable. Nous avons chiffré ce que ce déplacement change sur un projet réel dans ce que l’IA accélère, et ce qu’elle n’accélère pas.

Ce que ça change concrètement pour une PME

Trois différences se voient dès les premières semaines.

Le cahier des charges devient facultatif. Vous n’avez plus à formaliser à l’avance un besoin que vous ne connaissez qu’en partie. La première version sert de langage commun, et c’est elle qui révèle les vraies contraintes.

Le risque change de camp. Un forfait sur résultat déplace vers le prestataire le coût des erreurs d’estimation. C’est aussi ce qui l’oblige à dire non aux demandes qui n’apportent rien.

Le rythme devient hebdomadaire. Un point par semaine avec quelque chose de visible remplace un comité mensuel avec des diapositives. C’est moins confortable, et beaucoup plus rapide à corriger.

Quand ce n’est pas le bon modèle

Ce mode de travail ne convient pas à tout :

• Quand le besoin est parfaitement stable et déjà spécifié, un prestataire classique au forfait coûtera moins cher.
• Quand la contrainte principale est réglementaire ou contractuelle, la phase d’analyse ne se compresse pas, quel que soit l’outillage.
• Quand un logiciel du marché couvre déjà quatre-vingts pour cent du besoin, le bon conseil est de l’acheter, pas de le reconstruire.
• Quand personne, côté client, ne peut consacrer une heure par semaine au projet, la boucle de retour ne se ferme pas et le modèle perd son intérêt.

Ce dernier point est le plus souvent sous-estimé. Un FDE ne remplace pas la disponibilité de l’équipe métier : il en dépend.

Un produit livré vite ne sert à rien s’il reste introuvable. C’est pourquoi la question de la visibilité, et notamment du GEO et de la citation par les moteurs de réponse, se traite dans le même mouvement que le développement. Nos formules et leurs prix sont détaillés sur la page d’accueil.

À quoi ressemble une semaine

La description théorique laisse peu voir du travail réel. Voici le rythme que nous tenons sur une mission type, et il n’a rien d’exotique.

Lundi, deux heures avec les utilisateurs. Pas le décideur, les gens qui font le travail. On regarde par-dessus leur épaule pendant qu’ils traitent un dossier réel. C’est là qu’apparaissent les tableurs parallèles, les copier-coller entre deux outils, les règles que personne n’a écrites. Aucune réunion de cadrage ne fait remonter ça.

Mardi et mercredi, on construit. Le périmètre de la semaine est délibérément petit : une écran, un enchaînement, un rapport. Assez pour être utilisable, assez peu pour être jeté sans regret.

Jeudi, mise en ligne. Sur l’environnement réel, avec les vraies données, accessible aux personnes vues lundi. C’est le point le plus important de la semaine, et celui que la plupart des projets repoussent au dernier trimestre.

Vendredi, une heure de retour. Qu’est-ce qui a été utilisé, qu’est-ce qui a été contourné, qu’est-ce qui manque. Le contournement est le signal le plus utile : il indique que la solution ne correspond pas au travail réel, et il vaut mieux l’apprendre en semaine deux qu’en mois six.

Ce cycle produit un effet secondaire que nous n’avions pas anticipé au départ : les demandes des utilisateurs deviennent plus précises de semaine en semaine, parce qu’ils raisonnent sur quelque chose d’existant plutôt que sur une intention.

Les compétences qui comptent vraiment

Le métier est souvent présenté comme un poste d’ingénieur senior. C’est vrai pour la partie technique, mais ce n’est pas là que se joue la différence.

Savoir poser une question ouverte

« De quoi avez-vous besoin ? » produit une liste de fonctionnalités, généralement copiée d’un outil existant. « Montrez-moi comment vous faites aujourd’hui » produit un diagnostic. La première question fait perdre des mois.

Accepter de jeter son propre travail

Un ingénieur attaché à son code ralentit le cycle, parce qu’il défend au lieu d’écouter. Dans ce modèle, une partie du travail des premières semaines existe pour apprendre et sera remplacée. C’est un coût assumé, pas un échec.

Dire non avec un argument

Un forfait sur résultat oblige à refuser les demandes qui n’apportent rien, sous peine de ne jamais livrer. Refuser sans expliquer casse la relation ; expliquer le coût d’opportunité, en montrant ce qui sortirait du périmètre en contrepartie, la préserve.

Connaître la limite de sa compétence

Sur un sujet réglementé, comptable ou médical, l’ingénieur n’est pas l’expert et ne doit pas se comporter comme tel. Le rôle consiste alors à traduire fidèlement une règle formulée par quelqu’un d’autre, et à faire valider cette traduction.

Comment démarre une mission

Nous procédons toujours dans le même ordre, parce que chaque étape conditionne la précédente.

1. Un appel de vingt minutes. Contexte, douleur, enjeu chiffré si possible. À l’issue, nous disons si le sujet nous paraît traitable, et parfois que non.
2. Une demi-journée d’observation. Sur place ou en partage d’écran, avec les personnes concernées. C’est ce qui détermine le périmètre réel, souvent différent de celui annoncé.
3. Un forfait chiffré sous quarante-huit heures. Un périmètre, un prix, une date. Pas de fourchette, pas de jours-homme.
4. La première mise en ligne en une à deux semaines. Étroite, réelle, utilisable.

Si la deuxième étape révèle qu’un logiciel du marché couvre le besoin, nous le disons et la mission s’arrête là. C’est arrivé, et c’est le meilleur usage possible d’une demi-journée.

À retenir

• Un Forward Deployed Engineer part du processus métier observé, pas d’un cahier des charges. Il livre du logiciel en production, pas une recommandation.
• Le modèle devient abordable parce que le coût d’une première version est passé de plusieurs semaines à quelques jours, ce qui rend l’erreur peu coûteuse.
• La facturation se fait au forfait par périmètre. À l’heure, le prestataire rapide se pénalise lui-même.
• Le modèle échoue si personne, côté client, ne peut consacrer une heure par semaine au projet : la boucle de retour ne se ferme pas.
• Quand le besoin est stable et déjà spécifié, un prestataire classique au forfait coûte moins cher.

Ce que veut dire « cent six mille lignes »

Une ligne de code n’est pas une unité de valeur. Ce volume comprend les migrations de base de données, les tests, les fichiers de configuration et le code généré par les outils. Un développeur peut multiplier ce chiffre par trois en changeant de style de formatage.

Ce que le chiffre dit vraiment, c’est l’ampleur du périmètre couvert : authentification et gestion des rôles, parcours d’entrée en relation avec vérification d’identité, signature électronique, tableaux de bord, back-office d’administration, envois transactionnels, et l’infrastructure de déploiement autour. Sur un rythme classique, ce périmètre se planifie sur six à neuf mois.

Autre précision utile, parce que l’honnêteté sur les chiffres fait partie du travail : un de nos autres projets affiche un volume comparable, mais il s’agit pour l’essentiel d’un thème e-commerce du marché, dont seule une petite part a été écrite par nous. Nous ne comptons pas ces lignes-là dans nos réalisations.

Ce que l’IA accélère vraiment

Le premier jet

Écrire une couche d’accès aux données, un formulaire complet avec sa validation, une suite de tests d’intégration : c’est du travail connu, répétitif, et c’est là que le gain est le plus net. Ce qui prenait une journée prend une heure ou deux.

La traversée de l’inconnu

Intégrer une API que l’on découvre demandait des heures de lecture de documentation. Le gain vient moins de la génération de code que de la réduction du temps passé à comprendre.

Le travail ingrat

Migrations, renommages à grande échelle, mise à niveau de dépendances, rédaction des tests manquants. Ce sont des tâches à faible densité de décision et à fort volume, exactement le profil où l’assistance est la plus rentable.

Ce que l’IA n’accélère pas

C’est la partie qu’on lit rarement, et c’est elle qui détermine si un projet tient ses délais.

• Décider quoi construire. Aucune assistance ne vous dira quel produit mérite d’exister. Cette décision reste le goulet d’étranglement principal.
• Obtenir les réponses métier. Si le délai de réponse à une question fonctionnelle est de cinq jours, le projet avance au rythme de cinq jours par question, quelle que soit la vitesse d’écriture du code.
• Les dépendances externes. Un compte bancaire, un accès à une API réglementée, une validation juridique : ces délais sont incompressibles et sont la première cause de retard réelle.
• La qualité des données existantes. Reprendre un historique incohérent demande un travail d’analyse que rien ne compresse.
• La confiance. Un logiciel qui manipule de l’argent ou des données personnelles exige des vérifications qui prennent le temps qu’elles prennent.

Formulé autrement : l’IA a déplacé le goulet d’étranglement de l’écriture vers la décision. C’est une bonne nouvelle, à condition d’organiser le projet en conséquence.

La méthode qui rend le rythme tenable

Un forfait, jamais un compteur horaire

Facturer à l’heure quand on écrit vite revient à se pénaliser d’être efficace, et pousse à étirer les missions. Un forfait par périmètre aligne les intérêts : nous avons intérêt à livrer vite et juste, vous avez un budget connu à l’avance.

Un point par semaine, avec quelque chose qui tourne

Pas de diapositives, pas de comité mensuel. Chaque semaine, une version déployée que vous pouvez utiliser. C’est ce qui permet de corriger une erreur de cadrage à la deuxième semaine plutôt qu’au quatrième mois.

Le périmètre se négocie, la date ne bouge pas

Quand un imprévu survient, la variable d’ajustement est la liste des fonctionnalités, pas la date de mise en production. Cela impose de trier en continu, ce qui est précisément l’exercice qui manque à la plupart des projets qui dérapent.

La visibilité est intégrée, pas ajoutée après

Le rendu côté serveur, la structure des URL, les données structurées et l’accessibilité aux robots se décident au moment de l’architecture. Les rajouter après coup coûte plusieurs fois le prix, et c’est le cas de figure que nous rencontrons le plus souvent chez des clients qui arrivent avec un produit déjà construit. Le détail de ces choix est dans notre guide du GEO.

Les conditions pour que ça tienne

Trois conditions, et elles portent toutes sur le client plutôt que sur le prestataire.

1. Un décideur unique, disponible une heure par semaine. Pas un comité. Une personne qui peut trancher.
2. Un périmètre initial étroit. Un produit qui fait une chose et la fait entièrement, plutôt qu’une plateforme complète à moitié finie.
3. L’acceptation de jeter. Une part du travail des premières semaines sert à apprendre, et sera remplacée. C’est le prix de la vitesse, et c’est moins cher que de construire longtemps la mauvaise chose.

Sans ces trois conditions, le rythme de quatre-vingt-dix jours n’est pas atteignable, et il serait malhonnête de le promettre.

Cette façon de travailler porte un nom : c’est le métier de Forward Deployed Engineer. Nos formules et leurs prix sont détaillés sur la page d’accueil.

Comment se répartissent réellement les quatre-vingt-dix jours

La répartition surprend souvent, parce qu’elle ne ressemble pas à la courbe qu’on imagine. Voici l’ordre de grandeur constaté sur la plateforme d’investissement, en semaines.

Deux enseignements. D’abord, le cœur fonctionnel, la partie que tout le monde imagine longue, occupe environ un tiers du temps. Ensuite, le dernier tiers, celui qui traite les cas limites et la sécurité, est aussi long que le cœur, et c’est lui qu’on sous-estime systématiquement dans les devis.

Le pic de risque ne se situe pas au démarrage mais autour de la semaine huit, au moment des dépendances externes. C’est là qu’un accès qui n’arrive pas fait glisser toute la suite, sans qu’aucune ligne de code n’y puisse quoi que ce soit.

Ce que nous avons jeté

Sur ce projet, trois travaux ont été écrits puis remplacés. Les mentionner n’est pas de la modestie mal placée : c’est le mécanisme même du modèle, et le taux de rebut fait partie du coût annoncé.

• Un premier parcours d’entrée en relation, conçu à partir de ce que le métier décrivait. La confrontation aux premiers utilisateurs a montré que deux étapes sur cinq n’avaient pas lieu d’exister. Trois jours de travail, remplacés en une journée.
• Un tableau de bord complet, dont trois indicateurs sur huit n’ont jamais été consultés. Nous les avons retirés plutôt que de les maintenir.
• Une couche d’abstraction construite pour supporter plusieurs prestataires de signature, alors qu’un seul a été retenu. Cas typique de généralisation prématurée, et le seul des trois qui aurait pu être évité.

Rapporté à l’ensemble, ce rebut représente environ une semaine sur treize. C’est le prix de la vitesse, et il reste très inférieur au coût de plusieurs mois passés à construire la mauvaise chose avec méthode.

Ce que le forfait implique de notre côté

Annoncer un prix ferme sur un périmètre partiellement connu suppose d’accepter trois contraintes, qu’il est honnête d’exposer.

Nous refusons certains projets. Quand la demande arrive sous forme d’un cahier des charges figé de quarante pages, le modèle ne s’applique pas et un prestataire classique fera mieux. Nous le disons plutôt que de prendre la mission.

Nous provisionnons l’imprévu. Un forfait qui ne prévoit pas de marge est un forfait qu’on renégocie, ce qui revient à facturer en régie avec une étape de conflit en plus. La marge est incluse dès le départ, et c’est aussi pour ça que le prix affiché n’est pas le plus bas du marché.

Nous arbitrons en continu. À périmètre constant et date fixe, chaque ajout implique un retrait. Cet arbitrage se fait au point hebdomadaire, avec le décideur, jamais en fin de projet.

Ce que nous ne promettons pas

Un produit livré en quatre-vingt-dix jours n’est pas un produit terminé. C’est un produit en production, utilisé, dont la suite se décide sur des usages réels plutôt que sur des hypothèses. La différence est considérable et rarement dite.

Nous ne promettons pas non plus que le rythme se transpose à un projet où une autorité de contrôle, un partenaire bancaire ou un service juridique impose son propre calendrier. Dans ces cas, la contrainte n’est plus la vitesse d’écriture du logiciel, et prétendre le contraire serait vous vendre un délai que nous ne tenons pas.

À retenir

• Une ligne de code n’est pas une unité de valeur. Ce que mesure un volume de code, c’est l’ampleur du périmètre couvert.
• L’IA accélère le premier jet, la découverte d’une API inconnue et le travail répétitif. Elle n’accélère ni la décision, ni les dépendances externes, ni la qualité des données existantes.
• Le goulet d’étranglement s’est déplacé de l’écriture vers la décision. C’est le projet qu’il faut réorganiser, pas seulement l’outillage.
• Le périmètre est la variable d’ajustement, jamais la date de mise en production.
• Trois conditions côté client : un décideur unique disponible une heure par semaine, un périmètre initial étroit, et l’acceptation de jeter une partie du travail des premières semaines.