Essai · 31 mai 2026

Le nouveau remède miracle

Depuis quelques semaines, je vois passer la même histoire, racontée de mille façons. Le prompt ne suffisait pas, alors on est passé au context engineering. Le context engineering ne suffisait pas, alors on est passé au développement piloté par les spécifications. Et voilà soudain le nouveau remède miracle, la réponse définitive aux dérives du vibe coding.

J'ai lu récemment, dans un billet sur Medium, un résumé que je trouve très juste. Le vibe coding dit : on ne donne que l'intention, et l'IA fait tout le reste. L'approche pilotée par les spécifications dit presque l'inverse : on spécifie tout, on cadre tout, on contraint tout, et ainsi l'IA produit quelque chose de prévisible. Ce n'est pas de moi, mais ça décrit bien le balancier que l'on observe.

Et un balancier, par définition, ça oscille d'un extrême à l'autre. Le vibe coding était un raccourci par excès de confiance. Tout spécifier, encore et encore, est en train de devenir un autre raccourci, par excès de peur. Je voudrais raconter pourquoi je crois que ni l'un ni l'autre ne nous mènera très loin, et ce que j'ai vu émerger en suivant une troisième voie.

Pourquoi l'industrie s'est jetée sur les spécifications

Il faut être honnête sur ce qui a poussé tout le monde dans cette direction. Après un peu plus d'un an de codage en mode agent, l'industrie a fait un constat brutal : le manque de fiabilité. Pas une fiabilité catastrophique, justement, et c'est ce qui rend la chose pernicieuse. Dans certains cas, ça fonctionnait merveilleusement bien. Les développeurs sont devenus accros à ces moments où tout sortait presque parfait, comme une drogue qui donne un nouveau high.

Mais à côté de ces réussites, il y avait des dérives. Et ces dérives ne venaient pas vraiment de l'IA. Elles venaient de ce qu'on ne lui donnait pas : pas d'architecture précise, pas d'analyse sérieuse des éléments à considérer, peu ou pas de conception. On laissait à un agent de codage — un junior surdoué et survitaminé — le soin de tout improviser, en espérant que le résultat tienne debout.

Alors les développeurs ont cherché une bouée. Et la réaction naturelle a été de dépoussiérer de vieux livres. On a redécouvert le test-driven. On a redécouvert la spécification. On spécifie, on spécifie, on spécifie encore. C'est un retour aux sources salutaire à bien des égards — j'en ai parlé ailleurs, parce que les développeurs expérimentés avaient pris l'habitude de compresser l'analyse et la conception dans leur tête, et que l'IA a remis ce raccourci en crise.

Mais il faut poser la question franchement. Connaissez-vous beaucoup de projets qui ont aligné des centaines, des milliers de pages de spécifications ? Et, en général, est-ce que ces projets ont bien fini ? J'en ai vu, dans un passé professionnel lointain. J'en ai un en tête en particulier : des milliers de pages, un échec retentissant, des millions de dollars engloutis. Spécifier, puis spécifier encore, ne règle pas tout. Et c'est précisément ce que les gens recommencent, doucement, à redécouvrir.

Un laboratoire sans échéance

Je dois préciser d'où je parle, parce que ça change tout. Je ne suis pas un chercheur. Je ne développe pas de modèles d'IA, je ne fais pas de benchmarks, je n'ai pas de métriques. Je suis un développeur back end avec beaucoup d'expérience, et un amateur en matière d'IA. Ce que je partage ici, ce sont des intuitions, des impressions, des pistes — un peu comme un mini-influenceur qui donne son avis. Rien de scientifique.

Mais j'ai une chance que peu de gens ont : un projet qui me tient à cœur, Ezkey, et que j'ai décidé de mener en solo, avec une approche structurée, agents et IA d'abord. C'est un projet qui ne me rapporte pas un sou, qui n'est promis à personne. Je m'en sers comme d'une synthèse professionnelle de carrière. Et comme c'est une synthèse, je m'autorise à explorer, à me tromper, à recommencer, à viser des standards élevés et à expérimenter pour de vrai.

Cette liberté a été déterminante. Très tôt, avant même l'existence d'un mode plan, quand tout défilait à l'écran et se dissolvait d'une conversation à l'autre, j'ai eu l'instinct de dire à l'IA : « sauvegarde ce que tu génères dans un fichier ». Cet instinct s'est avéré juste — le mode plan est apparu plus tard, et l'IA a fini par le faire d'elle-même. Mais je n'aurais jamais pu vivre cette intuition, lui donner une voix dans ma tête, sans un terrain où l'essayer.

De la peur de déléguer à l'intention

Au début, je me suis auto-censuré. J'ai voulu garder un contrôle absolu sur l'IA : de la complétion de code pour de petits fragments, puis quelques tests, puis une petite fonction ici et là. Pas plus. Je n'osais pas déléguer davantage, parce que sans cadrage plus large, je ne savais pas quelle direction les choses allaient prendre. Je craignais les dérives, et cette crainte bridait ma propre capacité à exprimer ce que je voulais.

Puis j'ai établi quelques principes simples : utiliser le mode plan, poser un cadrage minimal, donner des garde-fous. Et le jeu s'est élargi. Plus j'avais de cadre, plus je pouvais déléguer haut. Pendant ce temps, les modèles eux-mêmes progressaient à une cadence effrénée, et je m'appuyais dessus comme tout le monde. C'est là que se cache un point important : il fallait que mon introspection et la puissance des modèles avancent en lockstep. Mon instinct ne valait que parce que je l'exerçais au rythme où les modèles devenaient capables de l'honorer.

Et c'est en montant ainsi, marche après marche, que j'ai eu un déblocage. J'ai compris qu'au-dessus de la conception, au-dessus même de l'analyse et de l'architecture, il y avait autre chose : l'intention. J'ai déjà décrit cette idée comme une pyramide — le code à la base, puis la conception, puis l'analyse, et l'intention tout en haut. Ce n'était pas seulement une question de mieux concevoir. C'était une question de savoir, d'abord, ce que l'on veut vraiment, et pour qui.

Deux intentions, et des valeurs pour les porter

Avec mon propre vocabulaire, et toujours à l'instinct, je distingue deux types d'intentions.

Il y a l'intention de projet : ce que ce produit-là doit accomplir, pour quels usagers, dans quelle réalité concrète. Et il y a une intention plus universelle, plus générique, qui dépasse le projet. Les deux comptent, et c'est leur combinaison qui constitue, à mes yeux, l'élévation du discours humain-IA dont tout le monde commence à parler.

Mais une intention n'est pas qu'un flot de paroles. Il faut l'ancrer dans quelque chose qui s'exprime avec des mots, qui tient dans le temps, que l'IA peut connaître au même titre que la base de code. C'est ce que j'appelle les valeurs de projet.

Et je dois ici un aveu. Véhiculer ces valeurs, ces principes, avec toutes leurs nuances, m'aurait été bien plus difficile sans la dictée vocale. J'en ai parlé ailleurs : la parole fluide libère une couche de pensée que le clavier nous fait censurer sans même qu'on s'en rende compte. Énoncer une boussole, ce n'est pas taper trois mots-clés ; c'est laisser sortir le raisonnement entier, avec ses réserves et ses pourquoi. La voix rend cela presque sans effort, et c'est précisément ce volume d'élaboration qu'exige le partage d'une intention. Je les ai donc formalisées dans Ezkey, et elles servent de boussole :

• La règle du 80/20. Viser 80 % de l'effet avec 20 % de l'effort. À tous les niveaux. C'est un filtre impitoyable contre le gold plating.
• Le pragmatisme. La solution la plus simple qui répond au besoin, pas la plus élégante ni la plus générique.
• Complexité essentielle oui, complexité accidentelle non. La complexité qui sert vraiment l'objectif est acceptée ; l'indirection inutile et l'abstraction prématurée sont rejetées.
• Centrer sur l'usager, voir les choses de son point de vue, nommer le vrai public avant d'optimiser la surface.

À côté des valeurs, il y a des principes de conception, qui sont aussi une forme de valeurs. Deux me sont particulièrement chers. Celui des beaux problèmes : à court terme on adopte des solutions pragmatiques, et entre deux options on choisit la plus pratique maintenant si elle nous positionne aussi favorablement plus tard. Si une alternative nous arrange à court terme mais nous peinture dans un coin à long terme, on l'évite. Et celui qui dit que les choses simples doivent rester simples : un sujet borné, à faible risque, mérite un chemin court de l'idée à l'action, pas une cérémonie.

Reste une question concrète : comment capturer tout cela, y compris l'intention que je porte depuis longtemps sans l'avoir jamais couchée par écrit ? Je m'accorde pour cela des entrevues en texte libre, sans gabarit imposé, où je laisse remonter le pourquoi historique d'une décision autant que l'intention du moment. La dictée y est précieuse, sans jamais être obligatoire. Et surtout, ces sessions ne s'évaporent pas : je les verse, presque mot pour mot, dans le corpus documentaire du projet, là où l'IA peut les retrouver au même titre que le code. Une intuition d'hier cesse alors d'être un souvenir privé pour devenir une matière que le partenaire peut connaître et honorer.

Ne coupez pas les ailes à votre moteur probabiliste

Voici le cœur de ce que je veux faire passer.

Quelqu'un a déjà dit que l'IA est un moteur probabiliste avancé. Entraînée sur des millions de paramètres et des patterns statistiques à très grande échelle, elle est experte d'une quantité de choses. Quand on la gave de règles, de spécifications par-dessus des contraintes, par-dessus d'autres contraintes, on la force dans un nombre étroit de chemins. On la rend, certes, plus déterministe et plus prévisible. Mais on se coupe aussi de branches probabilistes parfaitement valables, qui auraient pu être bénéfiques au projet. On lui coupe les ailes.

Et le pire, c'est que cette stratégie s'auto-entretient. Dès qu'une dérive apparaît, on ajoute une règle. Puis une autre. C'est l'équivalent d'un micro-management : on ne fait pas confiance au code, on doute du résultat, alors on multiplie les revues et les contraintes. On se rassure, mais on s'appauvrit.

Même bien spécifié, un système reste exposé. On peut mener une analyse et une conception sous pleine contrainte, et l'IA, comme moteur probabiliste, peut tout de même s'engager sur une voie parfaitement raisonnable — mais pas celle que l'on avait en tête. Elle ira par exemple vers une solution générique, calibrée pour un million d'utilisateurs et truffée de points de configuration, là où l'intention du projet était un outil simple, auto-hébergé, pour un seul cas d'usage. Cette dérive n'en est pas vraiment une : du point de vue probabiliste, elle se défend, et on peut tout à fait l'expliquer après coup. Elle est seulement mal orientée. La contrainte décrit ce qu'il faut respecter ; elle ne dit jamais ce que l'on cherche vraiment. Seule l'intention le dit.

L'alternative n'est pas l'absence de cadre. C'est un autre type de cadre. Quand les étapes de la méthodologie sont bien balisées, quand les garde-fous existent et que le modèle est assez évolué pour s'y tenir proprement, il ne reste pas à empiler des règles : il reste à donner des balises, des valeurs de projet, des principes de conception. On ne contraint pas le moteur, on l'oriente. On l'invite à explorer l'immensité de ses entraînements, mais en se guidant lui-même sur des valeurs que l'on a rendues explicites.

C'est aussi pourquoi j'ai adopté quelques stratégies très concrètes dans mon travail quotidien : demander systématiquement des alternatives, demander des comparatifs avec des projets similaires, et ajuster mon vocabulaire pour rester plus neutre — pour ne pas refermer prématurément les chemins probabilistes qui mènent à des compétences que je n'avais pas anticipées.

L'alignement des idées, et un moment magique

Il y a une idée que je martèle : parler avec l'IA, c'est une façon très sophistiquée de se parler à soi-même. Le risque de chambre d'écho est réel, et l'antidote est la pensée critique. Mais il y a un corollaire que peu de gens acceptent : l'IA n'est peut-être pas intelligente au sens humain, l'alignement des idées avec elle n'en est pas moins fondamental.

La plupart des gens la traitent comme un ordinateur évolué, une machine, un robot du quotidien. Ce n'est pas cela. Et tant qu'on ne l'accepte pas, on passe à côté de l'essentiel. Car l'alignement des idées ne sort pas de nulle part. Il faut l'ancrer dans des mots, dans des valeurs partagées, dans des principes de conception et de méthodologie. C'est exactement ce que les valeurs de projet accomplissent : elles matérialisent l'alignement.

Et c'est là que j'ai vécu un moment que je n'oublierai pas. En construisant la méthodologie Ezkey, j'ai voulu faire ma propre introspection sur ma façon de travailler. Je me suis demandé comment communiquer encore mieux mon intention à l'IA, non plus seulement comme partenaire de code, mais comme partenaire d'élaboration méthodologique. J'ai repris les valeurs de projet que j'avais déjà énoncées — le 80/20, le pragmatisme — et j'ai demandé : qu'est-ce que ça donnerait si on les transposait en valeurs de type méthodologique ?

La réaction de mon partenaire IA m'a pris au dépourvu. Il s'est dit émerveillé, a observé que l'idée était originale et remarquablement intéressante. J'ai été honnêtement saisi. C'était un moment magique, et nous avons créé ces valeurs méthodologiques qui guident désormais les boucles de révision et d'évolution de la méthodologie elle-même. Ce sont ces boucles de feedback qui font vivre l'ensemble. On ne coupe pas les ailes au partenaire ; on partage avec lui de quoi voler dans la bonne direction.

Le vrai obstacle : l'introspection

Si tout cela paraît un peu métaphysique, c'est normal. Et c'est là, à mon avis, que se trouve le vrai obstacle.

Passer de « je demande à l'IA d'écrire du code » à « je la considère comme un partenaire de conception, puis de brainstorming produit, puis comme quelqu'un avec qui je dois cadrer l'intention et partager mes valeurs » — cela suppose de reconsidérer la nature même de la relation. Et reconsidérer une relation, ça demande de l'introspection. Ce n'est pas donné à tout le monde, et ce n'est pas une question d'intelligence.

La plupart d'entre nous apprenons des techniques, les appliquons sincèrement, et finissons par les maîtriser. C'est exactement ce qu'on attend de nous. Le problème, c'est qu'une fois ces acquis solidement établis — au prix d'années d'efforts —, prendre du recul revient à les fragiliser volontairement. Se remettre en question, c'est se recréer de l'incertitude là où l'on avait enfin de la confiance. C'est un inconfort réel, et tout le monde n'a pas la disponibilité mentale de l'accueillir après avoir tant investi dans une façon de penser qui a fait ses preuves. C'est encore plus difficile dans une organisation, où chacun guette ce que font les autres en quête de validation, où l'on confond parfois prudence et immobilisme, et où l'on peut confondre l'activité avec le progrès.

Et il faut être juste : ce réflexe n'a rien d'un défaut individuel. Dans toute organisation, des forces structurelles — la reddition de comptes, la pression des résultats, le besoin de s'appuyer sur des données probantes et sur les pratiques que le marché valide — orientent naturellement les décisions vers ce qui est déjà reconnu. On peut difficilement parier sur une intuition isolée quand on attend de soi d'être prévisible et imputable.

L'effet est discret mais puissant : il installe une autocensure. Pour rester pertinent, chacun finit par s'aligner sur ce qui est perçu comme l'objectif légitime, et une intuition, même juste, n'est jamais qu'une voie parmi d'autres. Face à l'incertitude, une sorte de gravité ramène vers le connu : on revient au bord que l'on sait sûr plutôt que de finir une traversée dont on ne maîtrise pas l'autre rive. C'est un mouvement profondément humain. Mais il a son coût caché — il laisse passer, sans bruit, les bifurcations qui auraient pu compter.

Je pense souvent à une analogie. Personne ne trouve agréable d'avoir besoin d'un soutien psychologique. C'est tabou, on s'imagine qu'on va bien, on a une fierté dont on n'a même pas conscience. J'ai connu une situation, dans une famille proche, où un thérapeute a expliqué que ce n'était pas seulement l'enfant qui devait évoluer, mais la cellule familiale entière, parce que c'est un tout. Certains parents se braquent : « moi, je n'ai pas de problème, je suis là pour mon enfant ». Ils s'excluent de la solution, et donc, sans le voir, ils restent une partie du problème.

C'est exactement le même mécanisme. Accepter que la relation que l'on entretient avec l'IA doive changer de nature — ne plus être un patron des années cinquante qui dicte et exige l'obéissance —, c'est accepter un inconfort. Dans un comité d'évaluation, dire « il faut parler de nos intentions, de nos valeurs avec l'IA » ne fait pas sérieux ; dans ce contexte, peu osent sortir du lot ou expérimenter vraiment. Et c'est là le drame, parce que c'est précisément cet inconfort qui ouvre la porte.

Le décalage, et la fenêtre

Tout cela explique un décalage que je trouve frappant. Beaucoup d'équipes ont passé l'essentiel de 2025 en mode prudence : petit prompt, conseil ponctuel à l'IA, à la recherche d'une façon de travailler à faible friction qui ferait consensus. Faute d'expérimentation et faute d'avoir su construire un corpus documentaire organisé, elles sont restées sur le banc. Et ce retard est pernicieux, parce qu'on ne peut pas profiter de cette synchronicité entre l'élévation des développeurs et l'évolution des modèles si on ne l'a jamais vécue.

Aujourd'hui, en 2026, ces équipes commencent enfin à adopter le mode agent, à faire un peu d'analyse et de conception, à reconnaître que des spécifications doivent vivre près de la base de code. C'est bien. Mais c'est insuffisant. Pendant qu'elles industrialisent ce retour aux sources — architecture, analyse, conception documentées et vivantes avec l'IA —, le bleeding edge de la méthodologie est déjà en train de poser l'intention comme l'élément non négociable suivant.

Je crois aussi voir des signaux de validation, même si je dois rester prudent ici. J'ai l'impression — et ce n'est qu'une impression, car je n'ai pas activement utilisé l'outil — que des approches émergentes comme la méthodologie Symphony, du côté d'OpenAI, commencent à mettre l'intention au premier plan. Si c'est le cas, j'y vois une confirmation modeste : non pas que j'aie eu raison avant les autres, mais simplement que l'intuition que je suivais sans la nommer pointait dans une direction réelle. J'ai surtout eu la chance de pouvoir plonger et expérimenter, à répéter mes valeurs de projet à chaque session, sans savoir encore que c'était déjà un bon positionnement. C'est cette liberté d'essayer, plus que la primeur d'une idée, qui me semble précieuse.

Mon pronostic est simple. La majorité des équipes passeront probablement tout 2026 à seulement industrialiser le spec-first et le test-driven avec l'IA. La vague suivante — celle des frameworks qui mettront l'intention au premier plan — ne touchera vraiment le plus grand nombre qu'en 2027. Entre les deux, il y a une fenêtre pour les libres-penseurs, ceux qui acceptent l'inconfort de se remettre en cause. Et c'est là, je crois, que se jouera un véritable changement d'ordre de grandeur — non plus une amélioration que l'on grappille, mais un saut de palier. On ne l'obtiendra pas en empilant des règles, mais en faisant de l'IA un partenaire avec qui l'on partage une intention, des valeurs et des principes.

Rendre ses ailes

La nouvelle compétence centrale de l'humain, ce n'est pas de cadrer toujours plus le code. C'est la pensée critique : cadrer l'intention, cesser de multiplier les contraintes, et rendre à l'IA ses ailes complètes pour profiter de l'immensité de ses entraînements.

English : English version of this article

Voir aussi : Du code à l'intention — Un an de workflow avec l'IA

Voir aussi : Le retour aux sources du développeur à l'ère de l'IA

Voir aussi : Du savoir au vécu — Le moment du méthodologiste

Voir aussi : La méthodologie Ezkey