L’ingénierie probabiliste et l’employé 24/7

• Le développement logiciel bascule discrètement de systèmes déterministes vers des systèmes probabilistes, et à l’ère où des agents IA génèrent, relisent et fusionnent du code pendant la nuit, le rôle des développeurs et la structure des organisations changent en profondeur
• Au sein des équipes AI-native, les rôles montent en gamme tout en se fragmentant vers le bas, avec le risque que les tâches simples de gestion des sorties d’agents se figent en nouvelles catégories d’emplois faiblement rémunérés
• Alors que le coût de génération du code tend vers zéro, la production de code explose comme dans le paradoxe de Jevons, mais le défi central est cette asymétrie : la génération est devenue bon marché, pas la vérification
• Les ingénieurs juniors, qui s’appuient sur l’IA pour produire dès le départ un code poli, font déjà face à une crise de formation au débogage, au jugement et à l’art du métier
• Le modèle utilisé aujourd’hui est le plus faible parmi ceux qui seront utilisés à l’avenir ; les organisations doivent donc bâtir non pas pour les capacités actuelles, mais pour des systèmes adaptés à des modèles futurs qui ne sont pas encore sortis

---

Le passage à l’ingénierie probabiliste

• L’industrie du logiciel s’est construite pendant des décennies sur un contrat déterministe : on écrivait le code, on le testait, on le déployait, avec la garantie qu’il fonctionnerait
• Ce contrat est en train de se rompre, et chez les meilleurs opérateurs d’entreprises AI-native, le codebase devient quelque chose dont on croit qu’il fonctionne, sans pouvoir encore en énoncer la probabilité exacte
• Le déclic est venu de la construction d’un projet parallèle appelé Compound Loop — un système qui fait s’affronter plusieurs modèles frontier pour écrire, relire et fusionner du code de façon autonome
  • En lançant le système sur de vrais problèmes avant d’aller dormir, on se retrouve au matin à trier une pile de PR qui n’existait pas la veille au soir
  • Certaines sont excellentes, certaines contiennent des erreurs, et certaines font émerger des questions qu’on n’avait pas posées
• Pour la première fois dans l’histoire du travail intellectuel, la personne qui quitte son poste n’emporte pas avec elle l’unique copie du cerveau
• Le concept du 9-9-6 est en pratique mort ; un employé 24/7 n’est pas quelqu’un qui travaille 24 heures sur 24, mais quelqu’un dont les agents travaillent en parallèle à grande échelle
• En 2026, la plupart des équipes ont toujours leur goulot d’étranglement non pas dans la saisie au clavier, mais dans la coordination, et la réorganisation des structures n’en est qu’à ses débuts

La fragmentation des rôles — montée et descente en même temps

• Au sein des équipes AI-native, la réalité est bien plus complexe que le récit simpliste selon lequel « tout le monde monte d’un niveau »
• Montée en gamme : les meilleurs ingénieurs deviennent des PM plus efficaces, les meilleurs PM deviennent des architectes système, et les meilleurs architectes se déplacent vers les questions de distribution, de croissance et de structure de marché
  • Pour ce groupe, c’est l’environnement de travail au plus fort effet de levier de l’histoire
• Fragmentation vers le bas : en parallèle, beaucoup d’ingénieurs ne deviennent pas architectes, mais se transforment en rédacteurs de specs, reviewers, baby-sitters d’agents
  • Leur rôle consiste à traduire l’intention en prompts lisibles par la machine, puis à noter le travail de la machine selon des critères qu’ils ne maîtrisent pas toujours eux-mêmes complètement
  • Une partie de ce travail est importante, mais une autre n’est qu’une version 2026 de la saisie de données, reconditionnée sous un nouveau vocabulaire
• Ces rôles fragmentés risquent d’aboutir à des salaires plus faibles, une valorisation moindre et, dans de nombreux cas, à une impasse de carrière
• L’écart salarial entre le tiers supérieur capable d’opérer efficacement une flotte d’agents et la couche intermédiaire qui ne fait que gérer les sorties sera plus important que l’écart salarial ingénieur-commercial de l’ère précédente
• Dans l’infrastructure IA, les performances du kernel, la conception de compilateurs et l’abstraction matérielle restent des moat défendables — au niveau le plus bas de l’ingénierie système, une précision déterministe élevée reste indispensable

Le paradoxe de Jevons — version code

• En 1865, l’économiste William Stanley Jevons a observé qu’une machine à vapeur plus efficace ne réduisait pas la consommation de charbon, mais l’augmentait — l’efficacité élargissait le champ de ce qu’il devenait rentable de motoriser
• Le logiciel vit aujourd’hui le même phénomène : à mesure que le coût unitaire d’écriture du code tend vers zéro, on n’en écrit pas moins, on en écrit beaucoup plus et on livre beaucoup plus
• Les entreprises qui croient que les lois de scaling sont infinies construisent déjà en conséquence, et ce sont elles qui deviendront les gagnantes d’une distribution en loi de puissance
• Ce qui se passe déjà sur le terrain :
  • Des agents ouvrent des PR, relisent le travail les uns des autres, puis les ferment sans qu’aucun humain ne touche le clavier
  • Des suites de tests auto-réparatrices se réécrivent d’elles-mêmes quand le code sous-jacent change
  • Des boucles d’expérimentation autonomes exécutent, mesurent et démontent 100 hypothèses pendant qu’une équipe n’en aurait autrefois lancé que 3
  • La documentation se met à jour automatiquement lors des merges en exploitant des compétences IA auto-améliorées
• Les équipes restructurées autour des agents atteignent 3x, 5x, 10x leur production d’il y a un an, et la courbe ne s’aplatit pas, elle continue de monter
• Deuxième leçon de Jevons : quand l’offre explose, la sélection devient le cœur du problème
  • Les opérateurs qui orientent une flotte d’agents vers les bons problèmes, filtrent ce qui a de la valeur dans les sorties et intègrent les résultats dans un ensemble cohérent accomplissent aujourd’hui le travail au plus fort effet de levier du logiciel
  • La valeur du travail n’est plus déterminée par l’effort de production, mais par la direction, la sélection et la cohérence

De l’ingénierie déterministe à l’ingénierie probabiliste

• L’ingénierie déterministe a dominé l’essentiel de l’histoire du logiciel : on écrivait, testait et relisait le code, et l’on pouvait comprendre son comportement dans un périmètre bien défini ; les bugs étaient reproductibles
• L’ingénierie probabiliste est déjà arrivée dans les équipes frontier : la majeure partie du codebase est générée par des systèmes probabilistes, revue sous pression temporelle, puis intégrée dans un tout qu’aucun humain n’a conçu à lui seul
• L’asymétrie fondamentale : la génération est devenue moins chère, pas la vérification
  • Un agent peut produire une PR de 500 lignes en une minute, mais il faut souvent plus d’une heure à un ingénieur senior pour repérer des bugs subtils comme des problèmes de concurrence, une mauvaise interprétation des specs ou une implémentation qui diverge de l’intention
  • La revue passe moins bien à l’échelle que la génération, et elle évolue plus mal que linéairement face au volume de sorties — plus le codebase est écrit par des agents, plus le contexte nécessaire pour évaluer chaque fragment augmente
• Au-delà d’une certaine échelle, le système produit plus que ce que les humains peuvent évaluer avec confiance, et l’exactitude devient probabiliste
• Exemples concrets : une condition de concurrence qui passe les tests 9 fois sur 10, une fonctionnalité parfaite en staging mais qui échoue sur une distribution de prompts inattendue, une migration qui corrompt silencieusement 1 ligne sur 10 000 et n’est découverte que trois semaines plus tard
• Proximal et Modular ont publié une recherche conjointe sur les tests de tâches de base des systèmes d’agents frontier, et les schémas d’échec documentés correspondent directement à ce phénomène
• Le mode de défaillance n’est pas l’effondrement spectaculaire, mais une dégradation lente et silencieuse — davantage de génération, une qualité de revue qui baisse, l’accumulation de défauts discrets et une érosion progressive de la confiance jusqu’à ce que des clients, un audit ou un incident en production révèlent le problème
• Les outils capables de résoudre correctement ce problème n’existent pas encore — des réponses culturelles comme de petits merges, des gates strictes, un scepticisme impitoyable face aux sorties trop polies, l’observabilité et une discipline de rollback peuvent aider, mais la culture ne scale pas au-delà d’une certaine taille d’équipe
• Celui qui résoudra ce problème définira le système d’exploitation des dix prochaines années du développement logiciel sérieux

Des rythmes de transition différents selon les secteurs

• Le passage de l’ingénierie déterministe à l’ingénierie probabiliste n’est pas uniforme ; il est stratifié selon les secteurs et les profils de risque

• Couche déterministe

  • Avionique, dispositifs médicaux, infrastructures de trading financier, systèmes de contrôle nucléaire, cœur des réseaux de paiement et autres domaines fortement régulés à haut risque
  • L’assistance par agents y sera adoptée prudemment, derrière de la vérification formelle, des simulations étendues et des chaînes de validation humaine
  • Ce n’est pas un manque d’imagination, mais une bonne appréciation du niveau de risque

• Couche probabiliste

  • Logiciels grand public, outils internes, systèmes marketing, majorité des SaaS, infrastructures de contenu, produits expérimentaux ou en phase initiale
  • Le coût d’un bug s’y limite à un rollback, des excuses ou un hotfix, et en échange on obtient une vitesse d’itération que le monde déterministe ne peut structurellement pas suivre
  • Les équipes probabilistes peuvent apprendre 10 fois plus par trimestre que leurs concurrentes déterministes

• Zone de convergence

  • À mesure que les modèles deviennent plus intelligents et que les harnais s’améliorent, la frontière de ce qui est « suffisamment sûr même de manière probabiliste » continue de se déplacer
  • Des méthodes probabilistes pénètrent déjà par tranches de 10 % à partir du bas dans des domaines qui paraissent encore déterministes, comme l’assurance, la santé ou certaines parties de l’infrastructure d’entreprise
  • Les pionniers de l’ingénierie probabiliste reconstruisent des garde-fous déterministes — vérifications formelles, chemins critiques validés, systèmes hybrides où la génération probabiliste est bordée par une vérification déterministe
• Les gagnants des dix prochaines années seront les équipes qui savent dans quelle couche elles se trouvent, qui résistent à la tentation de prétendre appartenir à une autre, et qui placent avec précision les frontières dans leur propre stack

La flotte d’agents (Agentic Fleet)

• Le « poste d’usine » n’est pas une bonne métaphore — l’ouvrier d’usine était le système en voie d’automatisation, ce qui n’est pas le cas ici
• La bonne métaphore est celle d’une flotte d’agents — même si le mot « flotte » suggère un ordre, une hiérarchie et une fiabilité que la réalité n’a pas encore
  • En pratique, ce que pilotent la plupart des opérateurs ressemble davantage à une nuée de sous-traitants fragiles qu’à une marine bien entraînée
  • Les agents ont des capacités inégales, des comportements probabilistes, sont parfois sûrs d’eux tout en ayant tort, et coûtent cher à exécuter à grande échelle
  • La couche d’orchestration casse, les fenêtres de contexte explosent, et le coût de l’inférence apparaît sur des factures qu’on préfère ne pas montrer au conseil d’administration
• Malgré cela, l’idée de flotte reste valable : composition (des agents différents pour des tâches différentes), coordination (handoffs, dépendances, escalades), chaîne de commandement (décision de mission, règles d’engagement, revue des résultats), travail en rotation (ils continuent à travailler dans le cadre des consignes pendant que le commandant dort, puis rendent compte le matin)
• Une bonne flotte ne se définit pas par son volume de production, mais par la cohérence de ce qu’elle produit
• Nouvelle forme de travail :
  • Le matin, triage et merge
  • Au milieu de la journée, travail humain à fort effet de levier — conversations clients, stratégie, décisions produit, rédaction des specs qui piloteront l’exécution nocturne
  • L’après-midi, revue et réorientation quand les premiers agents reviennent
  • En fin de journée, faire ce que la génération précédente ne faisait pas : le handoff — mettre le travail en file d’attente et transmettre à la flotte d’agents les specs à tenter pendant la nuit ; une partie sera erronée, une autre brillante, et seuls les humains peuvent juger la différence

Construire pour des modèles qui ne sont pas encore sortis

• Point martelé de façon constante ces dernières années : le modèle que vous utilisez aujourd’hui est le plus bête de tous ceux que vous utiliserez plus tard
• Cela ne garantit pas pour autant une progression parfaitement fluide — coûts, latence, fiabilité et limites de scaling peuvent compliquer la courbe
• Mais ce pari de direction est bien étayé par ce qu’on observe dans la couche infrastructure : les capacités frontier dépasseront de façon significative celles d’aujourd’hui dans les 6 à 12 prochains mois, et l’écart entre les meilleurs modèles actuels et ceux d’ici un an pourrait être plus grand que celui entre l’an dernier et cette année
• Implication stratégique : les organisations doivent construire non pour les modèles actuels, mais pour la capacité à exploiter des modèles qu’elles ne possèdent pas encore
  • Savoir écrire des specs, culture de la review, instrumentation de l’observabilité, exploitation d’une flotte d’agents, rituels de formation pour préserver les compétences des juniors — tout cela constitue une structure d’échafaudage pour 2027-2028, pas seulement pour les capacités de 2026
• Les entreprises qui bâtissent cet échafaudage dès maintenant absorberont le prochain saut de capacités comme un effet de levier ; celles qui attendent la maturité des outils passeront leur première année à apprendre ce que les early movers savent déjà
• Il faut être prêt à surinvestir dans les specs, la review et la discipline opérationnelle au-delà de ce que les modèles actuels exigent
• L’insignifiance de cette époque n’annonce pas son arrivée d’elle-même — elle se manifeste comme une incapacité progressive à suivre des équipes qui, un an plus tôt, n’étaient pas visiblement meilleures

Les muscles qu’on risque de perdre

• L’idée selon laquelle l’IA va soit stratifier définitivement la société, soit la démocratiser dans l’ensemble repose sur un fait : les humains excellent à optimiser le chemin de moindre résistance
• Thèse centrale : si l’on ne construit plus directement, on perd aussi la capacité à évaluer ce qui a été construit
• On le voit déjà : des ingénieurs juniors qui s’appuient sur l’IA dès leur première semaine livrent vite et produisent un code poli, mais quand le modèle échoue d’une manière imprévue, ils ne trouvent pas le bug — parce qu’ils n’ont pas développé ce modèle mental du système qui ne se forge qu’en luttant à 2 heures du matin avec une stack trace pour la centième fois
• Le goût ne s’apprend pas en validant un brouillon déjà poli, le jugement ne se développe pas en acceptant en 5 secondes la réponse plausible d’une machine au lieu de passer un après-midi sur un problème difficile, et l’artisanat ne s’acquiert pas en relisant le travail d’un autre agent
• C’est la crise de formation que la plupart des organisations n’ont pas encore comprise
  • Le modèle d’apprentissage par compagnonnage du logiciel (le junior livre de petites choses → le senior relit → le junior absorbe le goût à travers les corrections en rouge) s’effondre — le junior livre via des agents, et le senior relit des sorties d’agents au lieu de sorties humaines
  • D’où viendra l’artisanat de la prochaine génération ? Comment entraîner le goût sans répétition ? Comment remplacer le mentorat quand la personne mentorée n’a pas écrit elle-même ce qu’on lui demande d’améliorer ?
• Dans la plupart des organisations traditionnelles, les ingénieurs seniors actuels sont la dernière cohorte à avoir été pleinement formée selon les anciennes méthodes
• Réponse équilibrée : de façon intentionnelle et régulière, sur quelque chose d’important, faire soi-même les choses à l’ancienne, sans flotte — la plupart de vos pairs ne conserveront pas ce muscle, et cela peut faire la différence dans dix ans

Ce qui est inquiétant

• Cet essai ne débouche volontairement pas sur un optimisme facile — faire comme si le changement n’allait pas arriver n’empêchera pas son arrivée
• Le travail a déjà changé pour toujours, et il le fait à la vitesse de l’IA, de manière évolutive et progressive
• Les humains reprendront leurs journées pour les tâches qui ont réellement besoin d’eux, et les machines reprendront les nuits pour les tâches qui n’ont jamais été qu’un travail répétitif
• Parmi les scénarios plausibles des prochaines années :
  • une couche d’employés épuisés par la charge de review
  • une couche de rôles fragmentés dont les systèmes ont besoin mais qu’ils ne récompensent pas
  • une génération de juniors incapable de développer l’art du métier sur lequel les seniors actuels fondent leur jugement
  • des équipes qui confondent volume de sorties et qualité du travail, et ne voient l’écart qu’au moment des incidents
  • un écart qui se creuse continuellement entre les organisations qui ont bâti les muscles opérationnels pour le prochain modèle et celles qui ne l’ont pas fait
• Message central : construisez une organisation pour les modèles que vous n’avez pas encore, fabriquez parfois vous-même les choses difficiles pour ne pas oublier comment faire, envoyez votre flotte nocturne et dormez bien en sachant que le travail avance — mais restez conscient qu’une partie de ce qui reviendra pourra être fausse d’une manière que vous n’êtes peut-être plus entraîné à voir
• L’employé 24/7 n’est pas une promesse, mais une réallocation et un pari sur un avenir d’ingénierie probabiliste — le pari que l’humain dans la boucle restera assez affûté, honnête et bien formé pour mériter d’y être, et que l’organisation autour de lui sera construite non pour les modèles d’aujourd’hui, mais pour des modèles qui ne sont pas encore sortis