Le futur du delivery produit ne se jouera pas sur le meilleur LLM

Quand on parle d’IA appliquée au delivery produit, la conversation tourne presque toujours autour des outils et des modèles. C’est compréhensible : c’est ce qui bouge, ce qui se voit, ce qui se démontre en cinq minutes. Mais ce n’est pas là que se trouve l’actif durable.

Chaque semaine apporte son nouvel outil de prototypage, son nouvel assistant de code, son nouveau modèle qui bat le précédent sur un benchmark. Les comités de direction demandent quel outil adopter, les équipes comparent les abonnements, et l’on finit par croire que la performance d’un delivery assisté par IA dépend du bon choix de stack.

Nous pensons que c’est une erreur de perspective. Depuis plusieurs mois, nous intégrons l’IA à chaque étape de notre manière de concevoir et de livrer des produits : cadrage, design, développement, QA, exploitation. Ce que nous en retenons tient en une phrase : l’IA ne vaut que ce que vaut le contexte qu’on lui donne. Et ce contexte, personne ne vous le vendra. Il se construit, projet après projet, décision après décision.

Trois couches, une seule qui compte vraiment

Pour y voir clair, nous découpons le delivery assisté par IA en trois couches.

La première, c’est le tooling : les environnements dans lesquels travaillent les équipes. Figma, Lovable, Cursor, Jira, Confluence, GitHub, les outils d’observabilité. C’est la couche la plus visible, celle dont on parle en réunion.

La deuxième, ce sont les modèles : Claude, GPT, Gemini et les modèles spécialisés qui tournent à l’intérieur de ces outils. Ce sont les moteurs. Ils raisonnent, génèrent, analysent, synthétisent, écrivent du code.

La troisième, c’est le socle de connaissance produit : tout ce que l’équipe sait et a décidé à propos du produit. La vision, les objectifs, les personas, les parcours, les règles métier, le périmètre du MVP, les états et les cas limites, les critères d’acceptation, l’architecture, le modèle de données, la stratégie de test, les incidents, ce que la production nous a appris.

C’est la couche la moins spectaculaire. C’est aussi la seule qui vous appartient vraiment.

Les outils et les modèles sont faits pour être remplacés

Il y a trois ans, la plupart des outils que nous utilisons aujourd’hui n’existaient pas, ou pas sous cette forme. Rien ne permet de penser que ceux de 2028 seront les mêmes. Les modèles évoluent encore plus vite : celui qui fait référence ce trimestre sera dépassé dans quelques mois. Ce n’est pas un problème, c’est le rythme normal d’un marché qui progresse.

Nous en tirons une règle simple : ne jamais construire notre méthode de delivery autour d’un outil ou d’un LLM particulier. Nous utilisons d’ailleurs déjà des modèles différents selon les tâches. On n’attend pas la même chose d’un modèle pour synthétiser des entretiens utilisateurs, relire une pull request ou analyser un incident. Ce choix doit rester ouvert, et révisable à tout moment.

Une méthode adossée à un outil vieillit avec lui. Une méthode adossée à un socle de connaissance gagne en valeur à chaque projet.

Le contexte, c’est ce qui rend l’IA pertinente

Demandez à un modèle de rédiger les spécifications d’un parcours de souscription. Sans contexte, il produira un texte plausible, propre, générique. Il ignorera que vos conseillers peuvent reprendre un dossier en cours, que telle pièce justificative n’est exigée qu’au-delà d’un certain montant, que vous avez abandonné la signature en deux étapes après un test raté l’an dernier.

Donnez-lui les règles métier, les décisions prises, les cas limites identifiés, les retours de production : il produira quelque chose d’utilisable. Le modèle n’a pas changé. Le contexte, si.

C’est pourquoi, avec l’IA, la qualité du contexte devient une infrastructure critique du delivery, au même titre que l’intégration continue ou l’hébergement. Pour jouer ce rôle, le socle doit être propre, centralisé, structuré, versionné, lisible par un humain et exploitable par une machine.

Notre préférence actuelle : faire vivre une grande partie de cette connaissance dans des fichiers Markdown versionnés dans Git, au plus près du code. Le format est simple, durable, lisible par tout le monde et par tous les modèles. Chaque modification est tracée, chaque décision a un historique, on peut revenir en arrière. Ce n’est pas un dogme : c’est le choix qui répond le mieux aujourd’hui à ces exigences.

Garbage in, garbage out, mais à très grande vitesse

Dans la plupart des organisations, la connaissance produit est éclatée. Une décision dans un fil Slack. Une règle métier dans une page Confluence que personne n’a mise à jour depuis deux ans. Une maquette Figma qui ne correspond plus à ce qui est en production. Des tickets Jira qui se contredisent. Et une bonne partie de l’essentiel dans la tête de deux ou trois personnes.

Les équipes compensent ce désordre en permanence, sans même s’en rendre compte : elles posent la question au bon collègue, elles se souviennent du contexte, elles sentent qu’un ticket est bizarre. Un agent, lui, prend au sérieux tout ce qu’on lui donne. Il appliquera consciencieusement la règle obsolète, s’appuiera sur la maquette périmée, choisira l’un des deux tickets contradictoires. Et il le fera vite, bien formaté, avec assurance.

Le meilleur modèle du monde ne corrige pas un contexte faux. Il produit simplement des choses fausses beaucoup plus vite.

Un socle propre produit de l’accélération. Un socle sale industrialise la confusion.

Une connaissance qui grandit avec le produit

Attention à un contresens : le socle n’est pas un référentiel figé qu’on rédige en début de projet puis qu’on archive. Son contenu évolue en permanence. Ce qui est durable, c’est son existence : un endroit structuré, centralisé et versionné, indépendant des outils et des modèles qui le consomment.

Il s’enrichit à chaque étape du delivery. Quand on imagine et qu’on cadre, il accueille la vision, le besoin, les personas, les parcours, le périmètre du MVP et les premières règles. Quand on conçoit, il intègre ce que le prototype et les tests utilisateurs ont appris : décisions UX, états, erreurs, cas limites, design system. Quand on réalise, il se précise avec les contrats de fonctionnalité, les critères d’acceptation, les décisions techniques, l’architecture et les tests. Quand on opère, il se nourrit du monitoring, des incidents, des usages réels et des retours, qui font naître de nouvelles hypothèses et relancent le cycle.

Chaque étape hérite de la précédente et enrichit la même connaissance. La connaissance du produit progresse au même rythme que le produit lui-même. C’est précisément ce qui manque à la plupart des projets : une mémoire qui ne se perd pas entre deux phases, deux prestataires ou deux départs.

Une seule vérité produit, plusieurs agents

Une fois ce socle en place, on peut y brancher des agents spécialisés. Un agent de cadrage analyse la matière brute, structure le problème, propose des parcours et une cartographie des fonctionnalités, repère les trous et les hypothèses non vérifiées. Un agent de design produit des parcours, des variantes, des prototypes et des états en s’appuyant sur le design system. Un agent de réalisation transforme le tout en contrats de fonctionnalité, en tickets, en plans d’implémentation, en code et en documentation. Un agent QA en tire une matrice de tests, des scénarios et des contrôles de non-régression. Demain viendront des agents dédiés à l’exploitation, à l’analytics ou à l’accessibilité.

Le point essentiel est ailleurs : aucun de ces agents ne possède sa propre interprétation du produit. Ils lisent tous le même socle, et proposent tous de l’enrichir. Le designer ne travaille pas sur une version du besoin différente de celle du développeur. La QA ne teste pas une règle que le PM a abandonnée la semaine précédente.

L’humain ne vérifie pas, il décide

Rien de tout cela ne fonctionne sans une petite équipe très expérimentée au cœur du dispositif. Chez nous, c’est un trio : un Product Manager, un Product Designer et un Lead Developer, épaulés par un DevOps ou un SRE quand le produit l’exige. Le PM garantit la valeur et la direction. Le designer garantit l’expérience et les parcours. Le Lead garantit la cohérence technique et la soutenabilité. Le SRE garantit qu’on sait déployer, observer et opérer le produit correctement.

On entend souvent que le rôle de l’humain, face à l’IA, serait de « vérifier les outputs ». C’est beaucoup trop réducteur. Le rôle de l’expert est plus fondamental : il est le garant de ce qui devient vrai dans le socle de connaissance produit.

Un agent peut proposer une nouvelle règle métier : le PM décide si elle est vraie, et si elle est utile. Un agent peut proposer trois parcours : le designer arbitre. Un agent peut proposer une architecture : le Lead en mesure les conséquences, puis valide ou refuse.

L’IA analyse, propose, transforme, produit, compare, vérifie. L’expert comprend, challenge, arbitre, valide et fait progresser le produit.

L’agent propose et produit. L’expert arbitre ce qui mérite d’entrer dans la connaissance du produit.

C’est aussi pour cela que nous ne croyons pas au discours selon lequel l’IA remplacerait les équipes. Elle déplace leur valeur : moins de temps à ressaisir, à reformuler, à produire mécaniquement ; plus de temps à comprendre, à décider, à assumer.

Plus vite, mais surtout plus large

Le premier bénéfice de l’IA est évident : la vitesse. Moins de ressaisie, moins de reformulation, moins de production mécanique. On passe plus vite du besoin au prototype, du prototype aux spécifications, des spécifications au code et aux tests.

Le second bénéfice est moins commenté, et nous le trouvons plus intéressant : la largeur d’exploration. Un designer peut explorer cinq variantes d’un parcours au lieu d’une. Un PM peut analyser deux cents retours utilisateurs au lieu de vingt. Un Lead peut comparer sérieusement trois approches techniques avant de choisir. Une QA peut envisager des scénarios auxquels personne n’aurait eu le temps de penser.

L’IA fait chuter le coût de l’exploration. On ne retient plus la première idée faute de temps pour en tester d’autres.

Plus de puissance, plus d’arbitrage

Il y a une contrepartie, et elle est de taille : plus il devient facile de produire, plus il devient important de savoir quoi ne pas produire.

Quand générer une variante, une fonctionnalité ou un écran ne coûte presque plus rien, la tentation est forte de tout garder. C’est ainsi qu’on fabrique des produits obèses, des backlogs sans fin et des socles de connaissance pollués par des décisions que personne n’a vraiment prises.

L’IA réduit le coût de production. Elle augmente mécaniquement le besoin d’arbitrage.

Hier, la question qui structurait une roadmap était souvent : « Avons-nous le temps de le faire ? » Demain, elle devient : « Avons-nous une bonne raison de le faire ? » C’est une question de jugement, de connaissance du métier, de sens produit. Exactement ce que des experts expérimentés savent faire, et qu’aucun modèle ne fera à leur place.

Ce qui restera

Les outils passeront. Les modèles progresseront. La valeur durable réside dans la connaissance du produit : sa qualité, son historique, et la capacité des humains à décider continuellement ce qui mérite d’y entrer.

Pour une direction produit ou technique, la bonne question n’est donc pas « quel outil d’IA devons-nous adopter ? », mais « notre connaissance produit est-elle en état d’être exploitée ? ». Est-elle centralisée ou dispersée ? À jour ou fossilisée ? Lisible par une machine, ou seulement par les trois personnes qui la portent ? Et qui, dans l’équipe, a la légitimité de décider ce qui y devient vrai ?

C’est sur ce terrain que nous travaillons avec nos clients. Pas pour ajouter une couche d’IA de plus, mais pour construire le socle qui permet à toutes les autres de produire quelque chose de juste.

Le futur du delivery assisté par IA ne se jouera pas sur celui qui aura le meilleur modèle. Il se jouera sur celui qui aura le meilleur contexte à lui donner.