Pourquoi votre produit construit avec l'IA semble générique

Mik Bry · 2026-08-21 · lecture ~10 min · IA · Vision

Un de mes propres projets tourne encore aujourd'hui. Rien n'y est techniquement cassé. Personne ne s'en plaint. Et il n'est jamais tout à fait devenu ce que je voulais construire — je serais incapable de désigner le moment précis où cela a dérapé, parce qu'il n'y en a pas eu. J'ai donné à un agent IA une pile de spécifications et je l'ai laissé travailler. Il les a toutes suivies, une par une. Ce qui lui manquait, c'était la raison pour laquelle je voulais construire ce produit. Cet écart a fini par se voir dans le produit lui-même. Le résultat était correct, techniquement solide, mais il ne répondait vraiment au besoin de personne.

Ce serait pratique d'accuser le prompt. Je ne crois pas que ce soit cela. À peu près à la même période, j'ai lancé un agent du même genre sur un autre chantier — celui-là avait déjà une suite de tests qui définissait, cas par cas, ce que voulait dire « terminé ». Il a atteint cette cible proprement, pendant la nuit, sans que je surveille quoi que ce soit. Même famille d'outils. Deux matins radicalement différents. Ce qui avait changé, ce n'était pas l'IA — c'était le fait d'avoir, ou non, déjà décidé, sous une forme que la machine pouvait vérifier, ce que je voulais vraiment.

Quand rien dans le produit ne reflète un utilisateur, un problème ou un point de vue précis, une autre équipe disposant des mêmes outils peut produire un résultat très similaire — un produit générique de plus.

01 — Un produit fonctionnel que personne n'avait vraiment demandé

Voilà à quoi ressemble, de l'intérieur, « des spécifications sans vision » — parce qu'entendu comme cela, on imagine facilement un produit visiblement cassé. Ce n'est pas le cas. Un cahier des charges dit à un développeur quoi construire : quel écran, quel bouton, quel champ. Il ne dit à personne pourquoi cette fonctionnalité compte plus qu'une autre, qui est censé ouvrir l'application à 21h un mardi, ni quel problème doit encore le gêner assez pour qu'il revienne le lendemain. Mon projet qui a dérivé avait beaucoup de la première catégorie d'instructions, et presque aucune de la seconde.

L'agent n'a échoué sur aucune tâche individuelle. Il les a toutes réussies, l'une après l'autre, dans l'ordre. Le résultat ressemble à une maison construite exactement selon un plan que personne n'avait vraiment décidé d'habiter. Chaque pièce était là où le plan le disait. Je n'avais simplement jamais choisi à qui remettre les clés, alors rien dans la maison ne semblait destiné à quelqu'un en particulier. C'est un échec étrange : pas de message d'erreur, pas de test qui échoue, rien qu'un relecteur pourrait signaler. Le code fonctionne. Personne ne lui avait dit, assez clairement, pour qui tout cela existait — alors rien dedans ne pointait vers un quelconque utilisateur. Cette partie-là, c'était la mienne, pas celle de l'agent.

02 — La même IA, avec une cible claire

Ce n'est pas une expérience contrôlée. Deux projets différents, deux semaines différentes — aucun scientifique n'appellerait ça une expérience, et moi non plus. Mais la comparaison est assez nette pour que je ne puisse plus accuser l'outil du dérapage du premier projet.

Les deux projets tournaient dans le même système interne que j'utilise au quotidien pour coordonner des agents de code — les tests, les revues, les vérifications d'intégration, tout le système. Ce système mérite son propre article, mais ce n'est pas le sujet ici. Ce qui compte, c'est ce que je lui ai confié : deux types d'instructions très différents.

Le second projet avait une suite de tests avant même que l'agent touche une ligne de code — des cas censés passer, des cas censés échouer, une frontière claire entre les deux. Avec cet objectif clair, l'agent a avancé vite et sans hésitation. Au matin, il avait convergé exactement vers ce que les tests décrivaient. Je n'avais surveillé aucune étape, et je n'en avais pas besoin.

L'agent a été le plus efficace quand l'objectif et la définition de « terminé » — une phrase claire disant ce qui doit être vrai pour que le travail compte comme fini — avaient déjà été posés par un humain. Quand je lui ai donné des instructions sans objectif clair, l'exécution — soignée pourtant — a dérivé. C'est tout le constat, et il est plus modeste qu'il n'en a l'air — mais il est à moi, tiré de ma propre expérience, pas d'une opinion à la mode lue cette semaine.

03 — Pourquoi l'IA converge si bien quand la cible existe déjà

Pour de plus en plus de produits logiciels, écrire le code n'est plus la partie la plus coûteuse. Je ne vais pas prétendre que c'est un mal — j'ai passé une bonne partie de ma carrière à faire à la main des tâches que je n'ai plus besoin de faire à la main, et la plupart ne me manquent pas.

C'est justement pour cela que l'IA excelle à reconstruire ce qui existe déjà. Cloner une application connue, copier la fonctionnalité d'un concurrent, réimplémenter un comportement dont la forme est déjà publique — un agent peut l'exécuter très efficacement, parce que l'intelligence de la tâche n'a jamais été dans le code. Elle était dans la décision d'origine, prise par quelqu'un d'autre, que cette fonctionnalité précise devait exister et fonctionner de cette manière précise. L'agent hérite de cette décision. Il n'a pas à en prendre une lui-même.

Ce que l'IA rend beaucoup moins coûteux, c'est le coeur du processus : transformer une décision produit en logiciel qui tourne. C'était vraiment la partie longue et coûteuse, et c'est bien qu'elle coûte moins cher aujourd'hui. Ce qu'elle n'a pas repris, ce sont les deux extrémités du processus — la décision qu'une chose précise doit exister, pour une personne précise, pour une raison précise, et, plus tard, la décision que ce logiciel est suffisamment fiable pour être confié à cette personne. Mon projet qui a dérivé avait une machine capable d'exécuter brillamment cette partie centrale. Elle n'a jamais eu, à aucun moment, quelqu'un pour lui donner le début de la phrase : une personne, une raison, un « ceci, et pas autre chose ».

04 — Le vrai avantage concurrentiel n'a jamais été l'outil

Tout fondateur qui a vu un produit construit avec l'IA se révéler décevant a déjà entendu la réponse habituelle : le vrai avantage, ce n'est pas l'application, ce sont les données, la distribution, la connaissance du métier, la marque. Cette liste n'est pas fausse. Elle s'arrête juste un cran trop tôt — elle nomme les symptômes sans dire d'où ils viennent réellement.

La connaissance d'un métier ne s'acquiert pas en un week-end de recherche. Elle vient du temps passé à comprendre en profondeur le problème concret de personnes réelles, bien après que le sujet a cessé d'être nouveau ou excitant. Ou l'intégration dans un flux de travail : cela vient du fait d'avoir observé ce qu'un utilisateur fait vraiment à son bureau, pas ce qu'une démo montre sur une scène. Même les données qu'on présente souvent comme un avantage ne deviennent réellement utiles que parce que quelqu'un a décidé ce qui méritait d'être conservé, et pourquoi. Une base de données ne devient pas précieuse en se remplissant toute seule.

Les agents peuvent très bien transformer ces avantages en logiciel, en fonctionnalités ou en processus une fois le problème clairement défini. Mais l'avantage lui-même vient d'avant : comprendre pour qui le produit existe, ce qui compte pour cette personne et pourquoi. Ce qui sépare un vrai avantage d'un produit générique n'a jamais été une question de compétence — c'est de savoir si quelqu'un avait déjà décidé, avant que tout cela soit construit, pour qui c'était et pourquoi cela comptait. La plupart de ces avantages durables remontent finalement à la même décision : quelqu'un a compris pour qui le produit existait et pourquoi.

05 — Construire le logiciel n'est qu'une partie du travail

L'IA a rendu beaucoup moins coûteux le fait de transformer une décision produit en logiciel qui tourne. C'est un changement important — mais il peut aussi détourner l'attention des fondateurs de l'essentiel.

Le code n'est qu'une partie du produit.

Il faut toujours quelqu'un pour trouver un problème qui vaut la peine d'être résolu, comprendre comment les gens s'en débrouillent aujourd'hui, décider quelle partie mérite vraiment d'être changée, expliquer le produit avec des mots que ces gens reconnaissent, et trouver un moyen de les atteindre.

Rien de tout cela n'arrive automatiquement parce que l'implémentation est devenue plus facile.

Plus le coût de construction baisse, plus il devient facile de passer des mois à produire des fonctionnalités que personne n'a demandées. Quand écrire une fonctionnalité de plus coûte quelques prompts au lieu de plusieurs semaines de développement, savoir dire non devient plus important, pas moins.

Le marketing fait partie de cette boucle lui aussi. Pas la publicité ajoutée après coup, mais le travail qui consiste à comprendre comment vos clients décrivent leur problème, ce qui capte leur attention, à quelles alternatives ils vous comparent et pourquoi ils vous feraient assez confiance pour essayer quelque chose de nouveau.

Ça, c'est du travail produit. Parler aux utilisateurs aussi. Observer ce qu'ils font vraiment après le lancement, et revoir ses hypothèses quand la réalité les contredit — cela aussi.

L'IA peut accélérer chacune de ces activités. Elle peut analyser des entretiens, rédiger un positionnement, explorer la concurrence et proposer des expérimentations. Mais elle ne supprime pas la nécessité de décider quelles preuves comptent et ce qu'on va en faire. Et vous ne pouvez pas rattraper cette décision en relisant plus attentivement après coup. Plus un outil devient familier, moins on le vérifie soigneusement — les relecteurs de code écrit par l'IA approuvent davantage et commentent moins à mesure qu'ils en relisent.

Références : Sur la baisse de vigilance des relecteurs au fil du temps : « Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code » (prépublication arXiv, juin 2026 — 400 relecteurs réguliers, 11 429 relectures ; plus d'approbations, 22 % de commentaires en moins) (en anglais). Sur la dynamique de fond — l'IA optimise ce qui est vérifiable, pas l'intention : Dex Horthy — « Harness Engineering is not Enough: Why Software Factories Fail » (en anglais). Vérifié le 3 septembre 2026.

06 — L'auteur ne disparaît pas — il monte d'un niveau

Coder a toujours été un moyen — une façon inventée de faire faire à un ordinateur ce que quelqu'un voulait, sans câbler des transistors à la main. À mesure que l'IA rend l'implémentation moins coûteuse, ce moyen devient simplement plus accessible. Et c'est très bien ainsi. Rendre un moyen technique moins coûteux n'enlève rien à ce qui donne au produit sa direction. La vision — la décision qu'une chose précise doit exister, pour une personne précise, pour une raison précise — n'a jamais été un moyen. C'est la raison pour laquelle un moyen est utilisé, tout court. Accélérer la construction ne rapproche pas de cette décision. Un compilateur plus rapide peut exécuter plus vite un programme déjà défini ; il ne décide pas de ce que ce programme devrait faire.

Si l'IA continue de progresser aussi sur ce qui ressemble à de la vision — détecter ce qu'un marché attend, esquisser le plan, choisir quelle fonctionnalité sort en premier — cette décision ne disparaît pas. Elle change de niveau. Quelqu'un doit encore décider ce que le système lui-même essaie de faire, et pour qui. Sur mon projet qui a dérivé, la solution n'était pas un agent plus intelligent. C'était moi, enfin présent pour répondre à « pour qui, et pourquoi » — une décision que davantage de capacité technique n'aurait pas prise à ma place.

Tout ce qu'on vérifie — les tests qui passent, un code propre, une relecture attentive — est un pari sur la même question : est-ce que ce qu'on a construit a vraiment servi la personne pour qui on le construisait ? Une machine peut vous aider à y répondre, mais elle ne peut pas en assumer la responsabilité — elle n'a que les cases à cocher. Savoir ce que « bien » veut dire pour une personne réelle, c'est votre rôle depuis le début.

La vision, ce n'est pas écrire chaque ligne. C'est rester responsable de la direction du produit : à qui il s'adresse, quel problème vous choisissez de résoudre, ce que vous apprenez de ceux qui l'utilisent, comment vous atteignez le client suivant, et quelle direction vous prenez quand la réalité contredit le plan de départ.

Le prompt peut tenir en une phrase. La décision qu'il contient doit encore venir de quelqu'un. Et ce quelqu'un, c'est encore vous.