# Pourquoi votre produit construit avec l'IA semble remplaçable

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

![Deux chemins partant du même point — l'un mène à une porte éclairée, l'autre se dissout dans le brouillard.](/assets/2026-08-21-authorship-manifesto-hero.png)
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ù ça 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 cette chose. 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 ça. À 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'outil. 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 une personne, un problème ou un point de vue précis, une autre équipe équipée des mêmes outils peut produire quelque chose de très similaire.
Ce que couvre cet article
1. [Un produit compétent que personne n'avait vraiment demandé](#s1) 2. [La même IA, pointée sur une vraie cible](#s2) 3. [Pourquoi l'IA converge si bien quand la cible existe déjà](#s3) 4. [Le vrai avantage concurrentiel n'a jamais été l'outil](#s4) 5. [Construire le logiciel n'est qu'une partie du travail](#s5) 6. [La vision ne disparaît pas — elle change de niveau](#s6)

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

Voilà à quoi ressemble, de l'intérieur, « des spécifications sans vision » — parce qu'entendu comme ça, on imagine facilement quelque chose de 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 pointait vers 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 ça existait — alors rien dedans ne pointait vers personne en particulier. Cette partie-là, c'était la mienne, pas celle de l'agent.

02 — La même IA, pointée sur une vraie cible

Ce n'est pas une expérience contrôlée. Deux projets différents, deux semaines différentes — aucun scientifique ne cautionnerait ce mot, et je ne vais pas l'employer non plus. Mais la comparaison est assez propre 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 l'appareil. Ce système-là mérite son propre article, pas celui-ci. Ce qui compte ici, 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 cette cible claire, 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é » avaient déjà été posés par un humain. Quand je lui ai donné de l'activité sans objectif clair, l'exécution — compétente 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 mon propre travail, 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 une perte — j'ai passé une bonne partie de ma carrière à faire à la main des choses que je n'ai plus besoin de faire à la main, et la plupart ne me manquent pas. C'est justement pour ça que l'IA excelle à reconstruire ce qui existe déjà. Cloner une application connue, copier la fonctionnalité d'un concurrent, réimplémenter quelque chose 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 chose 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 milieu 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 bouts 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 « ça, 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 décevoir 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. Prenez la connaissance d'un métier. Ce n'est pas une tâche de recherche qu'on boucle en un week-end — c'est ce qui reste quand quelqu'un s'est soucié du problème précis d'une personne précise bien après que ça a cessé d'être intéressant. Ou l'intégration dans un flux de travail : ça 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 clone quelconque n'a jamais été une question de compétence — c'est de savoir si quelqu'un avait déjà décidé, avant que tout ça soit construit, pour qui c'était et pourquoi ça comptait. La plupart de ces avantages durables finissent par remonter à cette 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 du bon endroit. 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 ça n'arrive automatiquement parce que l'implémentation est devenue plus facile. Plus construire devient bon marché, plus il est 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 de comprendre comment un client décrit son problème, ce qui capte son attention, à quelle alternative il vous compare, et pourquoi il vous ferait 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 — ça 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 générer des expériences. Mais elle ne peut pas vous dispenser de décider quelles preuves comptent, et ce que vous allez en faire.

06 — La vision ne disparaît pas — elle change de 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. Rien d'essentiel n'a été perdu, parce qu'un moyen est justement fait pour devenir moins cher. 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. Un constructeur plus rapide ne s'approche pas de cette décision comme un compilateur plus rapide s'approche d'un programme qui tourne. La vitesse n'a jamais été la contrainte. Si l'IA continue de progresser aussi sur ce qui ressemble à de la vision — sentir ce qu'un marché veut, 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'a jamais été un agent plus intelligent. C'était moi, finalement présent pour répondre à « pour qui, et pourquoi » — la seule donnée qu'aucune compétence supplémentaire n'allait jamais générer toute seule. 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 reste une responsabilité humaine.
Si vous voulez aller plus loin

Je relis des applications construites avec l'IA ou en vibe coding avant leur mise en production.

Commencer ici
Trust Report

Une revue automatisée de votre app et de son code, réalisée avec mes outils d'analyse. Vous obtenez les principaux risques, ce qui mérite l'attention avant le lancement et ce qui peut attendre. Si vous souhaitez parcourir les résultats ensemble, une revue avec moi est disponible en option.

349 € une fois
Obtenir le vôtre
Audit — besoin d'une revue plus approfondie ?

Architecture, paiements, accès, données clients, garde des clés de déploiement, logiciels tiers, et une recommandation de mise en production documentée par un CTO humain.

à partir de 1 200 € Contacter Mik