Essai personnel · 6 juin 2026

Le détour qui s'est imposé

J'ai commencé à rédiger cette réflexion le 14 mai 2026. Au départ, je voulais écrire un article assez classique sur la segmentation du marché, les budgets IA, les crédits, les modèles, les fournisseurs, les entreprises qui prendront de l'avance et celles qui devront rattraper.

Puis j'ai relu le brouillon, et quelque chose m'a dérangé.

L'article était intéressant. Il disait des choses que je crois encore justes. Mais tout à coup, je ne m'y retrouvais plus complètement. Je me suis entendu parler comme quelqu'un qui explique aux autres ce qu'ils devraient comprendre, comment ils devraient se préparer, comment ils devraient organiser leurs équipes, leur documentation, leurs budgets, leurs pratiques.

Et là, malaise. Je n'ai plus envie d'être cette personne-là.

Je ne veux pas continuer à être la belle-mère du monde corporatif. Dire « vous devriez faire ceci, vous auriez dû comprendre cela, vous allez frapper un mur ». Il y a peut-être du vrai dans certaines observations, mais ce n'est pas l'endroit où je veux me tenir.

Alors je vais prendre un détour. Peut-être même le vrai détour.

Je prends ma retraite. Je quitte la course.

Je ne quitte pas parce que l'IA ne m'intéresse plus. C'est plutôt l'inverse. Je quitte après avoir vécu, en fin de carrière, l'une des expériences intellectuelles les plus fascinantes de ma vie professionnelle. Mais je quitte aussi parce que cette expérience a rendu très visible quelque chose que je ne peux plus ignorer : je ne veux plus organiser ma vie autour de la performance, de la vélocité, de l'optimisation et de la production.

La phase d'abondance m'a transporté

Depuis 2025, les développeurs ont vécu une période assez particulière. Les modèles se sont succédé rapidement. Les IDE se sont remplis d'agents, de copilotes, de modes de composition, de chats contextuels et d'expérimentations parfois très généreuses. À plusieurs reprises, on a eu l'impression d'avoir accès, presque gratuitement ou presque sans limite, à des capacités qui auraient semblé impossibles peu de temps avant.

Je ne veux pas réduire cette période à une simple stratégie commerciale. C'était une période de conquête, bien sûr. Les grands fournisseurs avaient intérêt à habituer les développeurs, à intégrer les outils dans les IDE, à créer les réflexes, à faire entrer l'IA dans le quotidien.

Mais de mon côté, je l'ai vécu avec émerveillement.

Quand j'ai adopté le mode agent en mai 2025 et que j'ai commencé Ezkey comme laboratoire personnel, j'ai eu l'impression de remettre toute ma pratique à plat. Ezkey est devenu mon clean room. Un projet synthèse. Un endroit où je pouvais reprendre les fondations, tester les bonnes pratiques, refaire les choses proprement, revenir à l'analyse, à la conception, à l'architecture, aux tests, à la documentation vivante.

Il y avait aussi quelque chose de plus intime dans ce projet. Je pouvais me l'approprier entièrement. Je pouvais expérimenter, me tromper, recommencer, corriger, simplifier, changer d'idée, revenir sur une décision, refaire une couche que j'avais mal comprise. Le projet n'était promis à personne. Il n'avait pas de client qui attendait une livraison, pas de comité à convaincre, pas de budget de temps à défendre. Il pouvait devenir exactement ce que je voulais qu'il devienne, au rythme où j'arrivais à le comprendre, incluant ne jamais vraiment devenir quelque chose aux yeux du marché.

Je suis développeur back-end. Je fonctionne beaucoup à l'instinct. Je suis parfois brouillon. J'ai du mal à nommer les choses. J'ai du mal à garder le focus. Je fais des erreurs. Je crois avoir de bons réflexes et une certaine capacité d'introspection, mais la méthode ne m'est pas toujours venue naturellement.

L'IA a compensé exactement les lacunes qu'il fallait. Elle m'a aidé à structurer, à reformuler, à revoir, à documenter, à tester, à challenger mes décisions. Elle a rendu rentable un retour aux fondamentaux que j'avais longtemps gardé en partie dans ma tête. J'ai évolué en même temps qu'elle. Les modèles devenaient meilleurs, et moi aussi je devenais meilleur à collaborer avec eux.

C'est cette période qui a nourri plusieurs des articles que j'ai écrits. Le retour aux sources. L'intention. Le contexte. Le spec-first. La documentation qui cesse d'être une dette morale pour devenir un outil vivant. Tout cela, je ne l'ai pas simplement observé. Je l'ai vécu dans un projet qui me donnait de l'énergie.

La malléabilité retrouvée du logiciel

Cette énergie ne venait pas seulement de la nouveauté des modèles. Elle venait aussi d'une liberté que j'avais presque oubliée.

Avec les années, j'avais fini par accepter une évidence du métier : on ne peut pas tout reprendre. Le temps est compté. Les idées doivent être priorisées. Les équipes doivent s'aligner. Les budgets existent. Les systèmes déjà testés, déjà en production, déjà dépendants d'autres systèmes, ne se déplacent pas comme des pièces sur une table.

Un ancien directeur m'avait déjà dit, avec un humour très juste : « Marc, tu as plein de bonnes idées. Si tu veux travailler encore quarante heures pour les implémenter, tu peux le faire ! » Il avait raison. Derrière chaque bonne idée, il y a du risque, du temps, des tests, des régressions possibles, des arbitrages. Même quand l'idée est bonne, elle n'est pas automatiquement prioritaire.

À force de vivre ainsi, on finit par incorporer la contrainte. On apprend à censurer des pistes avant même de les formuler. On porte une petite tension de fond, comme une douleur musculaire tellement ancienne qu'on ne la remarque presque plus. On sait qu'il faudrait parfois réaligner, refactorer, documenter, extraire, mieux tester, introduire une file de messages, renforcer une séparation entre composants, revoir une architecture. Mais on sait aussi que la business attend autre chose, que la branche risque de rester ouverte trop longtemps, que l'énergie n'est pas infinie. Alors fini pour moi les features qui moisissent sur des branches pendant des années.

L'IA a rendu cette tension visible. Dans un projet personnel comme Ezkey, avec un contexte bien tenu, des tests solides et une liberté totale, j'ai retrouvé quelque chose que j'avais pratiquement oublié : le logiciel est malléable. Pas gratuitement. Pas magiquement. Construire la mauvaise chose coûte toujours cher. Un système peut devenir spaghetti, fragile, conceptuellement désaligné. Mais lorsque le contexte est explicite et que les validations existent, la possibilité de reprendre, réaligner, restructurer et améliorer redevient beaucoup plus concrète.

Ce moment a été une grâce. Avant que la budgétisation ne vienne remettre des compteurs partout, j'ai eu accès à une fenêtre où l'immensité du possible apparaissait de nouveau. Non pas comme une promesse commerciale, mais comme une sensation de praticien : je pouvais enfin essayer de faire les choses comme je pensais qu'elles auraient souvent dû être faites.

Le retour de la réalité collective

Cette fenêtre personnelle, j'ai voulu la transporter au travail.

À l'automne, un projet greenfield s'est présenté. Il a été question d'un projet AI-first. J'étais prêt. Ou du moins, je croyais l'être.

J'avais une expérience récente, intense, concrète. J'avais vu ce qui se passait quand on plaçait les documents de vision, les PRD, les user stories, les analyses préliminaires et les décisions techniques au cœur du dépôt. J'avais vu comment un corpus documentaire vivant pouvait devenir un partenaire de travail pour l'IA.

J'ai donc essayé de faire la même chose. Extraire ce qui existait de Jira, Confluence et ailleurs. Transformer des fragments en vision produit, en documents structurés, en premières user stories, en analyse utilisable par une équipe et par des agents. Il ne s'agissait pas, dans mon esprit, de faire de la documentation pour la documentation. Il s'agissait de créer les conditions pour qu'un vrai travail AI-first puisse commencer.

Et là, la réalité m'a frappé.

Personne n'était vraiment au même endroit. Beaucoup de gens en étaient encore à l'usage ponctuel : un prompt ici, une aide là, un petit gain local. C'est déjà quelque chose, et je ne veux pas le mépriser. Mais ce n'était pas la même chose qu'une approche de projet pensée autour d'un corpus documentaire vivant, d'une méthode explicite et d'une collaboration structurée avec des agents.

Le projet est rapidement revenu vers une dynamique plus classique. Des idées, des fragments, des listes d'épicerie, des envies de connecter des outils, des discussions sur les MCP, les intégrations, les raccourcis possibles. Mais peu de matière vraiment stabilisée. Peu d'analyse formalisée. Peu de conception soutenue. Peu de vision produit écrite de façon à pouvoir réellement guider le travail.

Je raconte cela avec prudence, parce que je sais aussi que j'ai commis des erreurs. J'ai fait certains choix qui n'étaient pas bons. Par exemple, j'ai poussé une piste de stack front-end qui ne s'est pas révélée appropriée. J'ai perdu de la crédibilité là-dessus, et je dois l'assumer.

Mais sur le fond méthodologique, je savais que quelque chose d'important était en jeu. Je voyais la distance entre ce que j'avais vécu dans Ezkey et ce que j'arrivais à faire vivre dans un contexte d'équipe. Cette distance m'a profondément déstabilisé et provoqué une remise en question profonde.

Le moment où je n'ai plus voulu recommencer

Il y a une scène intérieure qui m'a marqué.

Dans Ezkey, je venais de terminer un dossier exigeant autour de la cryptographie, de la rotation des clés, des lots de réencryption, de la représentation visuelle, des tests, des choix de conception. C'était un chantier qui m'avait demandé beaucoup d'attention, mais qui m'avait aussi donné une grande satisfaction. J'avais le sentiment d'avoir fait quelque chose d'élégant, de cohérent, de propre.

Puis, au travail, un chantier conceptuellement proche se présentait. Même famille de problèmes. Même besoin de rigueur. Même type de montagne à gravir.

Et au lieu de sentir l'élan, j'ai senti le poids.

Je me suis surpris à penser : non. Je viens de faire ce chemin. Je viens de vivre cette intensité. Je ne veux pas recommencer immédiatement dans un contexte où je n'ai ni le même contrôle, ni le même engagement collectif, ni la même liberté, ni la même joie.

Ce n'était pas de la paresse. Ce n'était pas seulement de la fatigue. C'était plutôt le sentiment très net d'avoir fait le tour du carré. J'avais vu le chemin. Je savais qu'il était intéressant. Je savais aussi qu'il serait long, exigeant, conflictuel, parfois ingrat. Et je ne voulais plus le refaire dans les conditions habituelles du monde corporatif.

La frustration est devenue colère. Une vraie colère. Pas une colère productive. Une colère qui ronge, qui rend moins lucide, qui rend moins disponible. Elle m'a suivi longtemps. Elle m'a forcé à regarder quelque chose que j'aurais peut-être préféré éviter : ce n'était plus seulement un désaccord de méthode. C'était un décrochage.

J'avais annoncé ma retraite en avril. Je quitterai à la fin août 2026. Entre les deux, je vis une drôle de période de dualité. Je suis encore là, mais déjà ailleurs. Je comprends encore les enjeux, parfois même très bien. Mais il n'est plus question d'en faire le centre de ma vie.

Le décor de fond reste vrai

C'est ici que je reviens au sujet initial de l'article.

Je crois encore que nous entrons dans une période où l'IA va segmenter fortement les entreprises. Certaines organisations sauront l'adopter de façon ambitieuse, méthodique et profonde. D'autres l'utiliseront avec prudence, dans un compromis entre gains réels et inertie organisationnelle. D'autres encore resteront limitées par leur parc, leur culture, leur sécurité, leur conformité ou leurs contraintes propres.

Je crois aussi que la question budgétaire arrive vite. Le passage de GitHub Copilot vers une logique de crédits IA et de facturation par usage au début juin 2026 n'est qu'un signal parmi d'autres, mais il montre quelque chose : la période où l'IA semblait être une abondance presque naturelle est en train de céder la place à une réalité plus comptable.

Quelques jours plus tard, un autre signal est venu s'ajouter : Fable 5 est apparu, puis l'accès au modèle a été suspendu presque aussitôt à la suite d'une directive gouvernementale américaine. Je ne veux pas construire toute une thèse sur un événement encore chaud, mais le symbole est fort. Une capacité peut disparaître non seulement pour des raisons de prix, de charge ou de stratégie commerciale, mais aussi pour des raisons réglementaires, politiques ou géostratégiques.

Pour une entreprise qui commencerait à organiser sa vélocité autour d'un modèle frontière précis, c'est un rappel brutal : la dépendance n'est pas seulement économique. Elle est aussi institutionnelle. Cela renforcera probablement, à long terme, la pression en faveur de modèles ouverts, de modèles moins coûteux, de solutions mieux adaptées à du matériel plus modeste, et d'une diversité de fournisseurs capable d'équilibrer le marché.

Les entreprises devront probablement apprendre à mesurer, arbitrer, optimiser. Quel modèle pour quelle tâche ? Quel budget pour quel résultat ? Quelle part de la vélocité vient du talent interne, et quelle part vient d'une capacité facturée par quelques grands fournisseurs ? Combien coûte une boucle mal cadrée ? Combien vaut une bonne spécification ? Où faut-il payer pour un modèle plus fort, et où faut-il plutôt améliorer la méthode ?

Tout cela est réel. Tout cela est important. Tout cela va occuper beaucoup de monde.

Mais je ne peux plus écrire comme si j'étais encore au centre de cette bataille.

Le contexte devient le produit

Depuis mon camping, au fond du bois, je vois aussi un autre vocabulaire se préciser. On parle de moins en moins seulement de prompt, et de plus en plus de contexte, de harness, de contexte produit. Le modèle reste important, bien sûr. Mais l'amélioration ne viendra pas seulement du prochain modèle, comme si l'on ne faisait qu'augmenter la fréquence d'un CPU. Elle viendra aussi de tout ce qui entoure le modèle : la mémoire, les outils, les validations, les boucles de rétroaction, la sélection du bon contexte au bon moment.

L'analogie matérielle me parle. Le modèle, c'est une forme de processeur. Le harness, c'est le reste de la machine : l'OS, la carte mère, les bus, les périphériques, les règles d'exécution, les mécanismes qui permettent au processeur de faire un travail fiable au lieu de tourner dans le vide. Le contexte engineering est alors une partie essentielle de cette architecture : décider ce que le modèle doit voir, ce qu'il doit oublier, ce qu'il doit retrouver, ce qui doit rester stable.

Et là, un terme me semble particulièrement révélateur : product context engineering. En français, je dirais volontiers gestion du contexte produit. C'est proche de ce que j'appelais jusqu'ici l'intention. Pas exactement le même mot, pas nécessairement le même cadrage, mais la même direction : faire remonter le discours au-dessus de la tâche, au-dessus du prompt, au-dessus même de l'analyse ponctuelle, pour donner au modèle une vision produit, une boussole, des valeurs, des contraintes de marché, une compréhension de ce que l'on essaie vraiment de construire.

C'est aussi pour cela que le vieux prompt de rôle me semble perdre de l'importance. Dire « tu es un expert React » a pu aider à une époque. Mais les modèles récents comprennent mieux les nuances du texte libre. Ils gagnent davantage quand on prend la peine d'expliquer en toutes lettres ce que l'on veut accomplir, pourquoi cela compte, quel genre de produit on cherche à faire vivre, quelles valeurs doivent guider les arbitrages. Encore une fois, tout pointe vers une élévation du discours.

Les blocs et les builders

Cette élévation ne veut pas dire que l'ingénierie logicielle disparaît. Au contraire. Il y aura toujours des gens qui construisent les blocs de base. Comme des briques LEGO, ces blocs doivent avoir des caractéristiques précises : résistance, stabilité, performance, sécurité, compatibilité, comportement prévisible sous certaines contraintes. Les bibliothèques, les runtimes, les systèmes critiques, les couches d'infrastructure continueront d'exiger de l'ingénierie profonde, avec ou sans IA.

Mais une grande partie du développement applicatif va probablement se déplacer vers un autre rôle : celui du builder. Le builder ne se contente pas d'empiler du code. Il choisit les bons blocs, comprend leurs propriétés, formule l'intention, construit le contexte produit, établit la vision, nomme les contraintes de marché, puis travaille avec l'IA pour assembler quelque chose qui répond à un problème réel.

Cette distinction me semble importante parce qu'elle réduit un faux débat. On ne cesse pas d'être ingénieur logiciel. On ne devient pas simplement un rédacteur de prompts. On devient, selon les contextes, tantôt concepteur de blocs, tantôt constructeur d'applications, tantôt gardien de contexte produit. Et c'est probablement cette combinaison qui redéfinira une partie du métier.

Le code comme artefact intermédiaire

Il y a un autre déplacement, plus discret, qui me semble tout aussi important : le rapport au code généré lui-même.

Une analogie me revient souvent. Quand les compilateurs génèrent du code assembleur, il est toujours possible de regarder ce qui a été produit. Pendant un temps, certains l'ont fait. Puis, dans la majorité des cas, on a cessé de le faire systématiquement. Non pas parce que l'assembleur n'avait plus d'importance, mais parce que la confiance s'est déplacée. Ce qui compte, c'est que le programme manifeste le bon comportement, respecte les contraintes attendues, produise les résultats mesurables, et que le compilateur soit suffisamment fiable pour que l'on n'ait pas à inspecter chaque instruction.

Je ne veux pas pousser l'analogie trop loin. Le code généré par l'IA reste du code source, donc un artefact humainement maintenable, révisable et responsable. Mais la cadence change le problème. Si du code est produit non plus en jours, mais en minutes ou en secondes, on ne peut pas raisonnablement imaginer que des humains liront systématiquement chaque ligne avec le même niveau d'attention qu'avant. La revue de code ne disparaît pas, mais elle doit changer de nature.

Le jeu s'élève donc aux deux extrémités. En amont, il faut mieux formuler l'intention, le contexte produit, les contraintes, les valeurs, les invariants. En aval, il faut mieux valider les comportements. Les tests ne sont plus seulement une bonne pratique de qualité. Ils deviennent l'interface de confiance entre l'intention humaine et la production accélérée par l'IA.

C'est là que le behavior-driven development, sous une forme ou une autre, reprend beaucoup de valeur. Décrire les comportements attendus, les scénarios, les limites, les contrats, les effets observables. Et autour de cela, conserver la discipline test-driven quand elle aide : tests unitaires, tests d'intégration, tests de non-régression, validations automatisées, garde-fous déterministes. On ne relira pas toujours tout le code comme on relirait chaque instruction assembleur. Il faudra plutôt prouver que le système fait ce qu'il doit faire, dans les conditions qui comptent.

Le builder ne sera donc pas seulement celui qui exprime une vision produit. Il sera aussi celui qui sait transformer cette vision en critères de validation. C'est peut-être là que se fera une partie de la nouvelle maturité : moins regarder chaque ligne comme si elle était écrite à la main, et davantage construire les conditions qui rendent la production de code fiable, mesurable et corrigeable.

Le mirage du x10

Cette idée rejoint une autre prudence que je veux garder. On entend souvent que l'IA permettra à un développeur de produire cinq fois, dix fois, vingt fois plus. Peut-être, dans certains contextes, sur certains types de tâches. Mais je ne crois pas que ce multiplicateur se traduira simplement par une profession devenue soudainement dix fois plus disponible pour la qualité, les outils internes, l'observabilité, la documentation et l'hygiène parfaite.

Une partie de cette capacité excédentaire pourrait aller vers des choses longtemps repoussées : meilleurs outils internes, workflows plus propres, dette réduite, dépendances mieux suivies, code mort éliminé, tests renforcés. Ce serait souhaitable. Mais croire que toute l'industrie va durablement fonctionner en mode qualité maximale, esprit critique maximal, production maximale et rigueur maximale me semble aussi naïf que les anciennes promesses de société des loisirs.

On nous a déjà annoncé que les gains de productivité libéreraient du temps pour la connaissance, la culture, la pensée, la vie plus riche. En pratique, l'humain et le marché s'adaptent. Les besoins montent. Les attentes montent. Ce qui était un luxe devient une commodité, puis une nécessité. On travaille autrement, mais on ne se sent pas nécessairement plus libre.

Je soupçonne qu'il se passera quelque chose de semblable avec l'IA. Les équipes trouveront un nouveau point d'équilibre. Les développeurs apprendront à doser le formalisme, l'analyse, l'esprit critique, le nombre d'agents, le niveau de validation et le coût acceptable. Puis ils se sentiront à nouveau débordés, simplement à un autre niveau d'abstraction.

Ce nouveau niveau est réel, et il est exigeant. Piloter des agents, maintenir l'intention, comparer des analyses, arbitrer entre plusieurs propositions, préserver l'intégrité conceptuelle d'un produit : ce n'est pas une activité légère. Ce n'est pas seulement écrire du code plus vite. C'est tenir dans sa tête un espace plus haut, plus abstrait, plus intentionnel. Pour moi, cet effort cognitif a été plus intense que je ne l'avais prévu.

Il y aura bien sûr des tâches plus légères, comme il y en a toujours eu : hygiène de code, mises à jour, petites validations, nettoyage, revue de surface. Mais le cœur du travail IA-first demande une qualité d'attention qui ne sera pas donnée à tout le monde en tout temps. L'humain va s'adapter, oui. Il va aussi chercher à réduire l'effort, à automatiser, à déléguer, à retrouver des moments de respiration.

Même la taille des équipes risque d'être touchée par cette dynamique. Plus le raisonnement est porté par un corpus documentaire vivant et par des agents capables de faire des recoupements, moins il est évident qu'un grand nombre de personnes désalignées produise un meilleur résultat. Certaines équipes deviendront sans doute plus petites, plus concentrées, plus alignées autour d'une vision partagée avec l'IA. Ce sera une force si l'alignement est réel. Ce sera un risque si l'IA ne fait qu'amplifier une chambre d'écho.

Ce sont des enjeux passionnants. Je les vois. Je les trouve importants. Mais je n'ai plus envie de les vivre comme une obligation professionnelle quotidienne.

Je choisis le lent

Je vais continuer à développer. Mais ce ne sera plus la même chose.

Développer ne sera plus mon identité centrale, ni la mesure de ma valeur, ni le moteur principal de mes journées. Ce sera une aspiration parmi d'autres. Je vais jardiner. Faire du vélo. Marcher. Cuisiner. Voyager peut-être, parfois loin, peut-être surtout près. Profiter d'un bon repas, d'une microbrasserie, d'une journée lente, d'un projet qui avance parce qu'il me plaît et non parce qu'on doit le livrer.

Je veux encore apprendre. Je veux encore comprendre ce qui arrive avec l'IA. Je veux encore explorer les modèles, les agents, les méthodes, les architectures, les outils. Mais à mon rythme, à mes conditions, dans un rapport qui ne sera plus gouverné par la performance ni par un cadre d'équipe à suivre.

Il y a une formule qui me vient : slow AI. Lent, mais attentif. Moins courir, mais regarder mieux. Moins produire, mais comprendre plus profondément. Moins chercher à convaincre, mais laisser des traces honnêtes de ce que j'ai vu, de ce que j'ai essayé, de ce qui m'a émerveillé, de ce qui m'a usé.

Peut-être que c'est cela, finalement, la tournure de cet article. Je vois venir l'âge budgétaire de l'IA logicielle. Je vois les entreprises entrer dans une période de rattrapage méthodologique, de dépendance fournisseur, d'optimisation des crédits, de métriques, de gouvernance et de choix difficiles.

Et moi, au même moment, je sors de la course.

Un peu par rejet. Un peu par amertume, même si on ne m'a pas forcé là. Plutôt parce que j'ai eu ma part. J'ai vécu, en fin de carrière, une accélération extraordinaire. J'ai vu ce que l'IA pouvait faire à un développeur qui accepte de se remettre en question. J'ai vu mes propres lacunes devenir moins lourdes grâce à un partenaire de travail qui m'aidait à les compenser. J'ai aussi vu les limites de cette énergie quand elle doit entrer dans une organisation qui n'est pas prête au même moment.

Le simple fait d'écrire ces lignes transforme ce récit d'expérience en sermon, mais c'est aussi une thérapie engageante et libératrice.

Toute cette aventure, cette valse avec l'IA, je veux plutôt la reconnaître pour ce qu'elle est : un passage. Un moment de bascule personnel au milieu d'un moment de bascule industriel.

Conclusion

English : English version of this article

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

Voir aussi : Rendre ses ailes à l'IA