Le vrai goulot d'étranglement de vos agents, ce n'est pas le modèle : c'est la mémoire que vous ne leur avez jamais construite
McKinsey vient de vous promettre une livraison logicielle 24 heures sur 24.
Dans "Rewiring software delivery for the agentic era", ils décrivent un monde où le sprint de deux semaines se comprime en un sprint quotidien, où les agents exécutent la nuit pendant que vous dormez, et où les équipes de huit à douze personnes cèdent la place à de petits pods qui supervisent. Une belle promesse, et le diagnostic de fond est juste presque à chaque fois. Mais, comme presque toutes les belles promesses de cabinet de conseil, elle saute la partie ennuyeuse : si vos agents ne font pas encore les nuits, ce n'est pas à cause du modèle qu'ils utilisent. C'est que vous ne leur avez jamais construit de mémoire.
Je n'écris pas ceci depuis le siège du consultant qui dessine l'operating model, mais depuis celui qui opère la plateforme où atterrissent ces agents. J'ai fait assez de DevOps et assez de gardes à trois heures du matin pour savoir une chose : un agent autonome la nuit, c'est exactement la même chose qu'un ingénieur d'astreinte fraîchement arrivé. Brillant, infatigable et parfaitement inutile si personne n'a écrit noir sur blanc comment le système fonctionne vraiment. Le modèle lui donne un cerveau. Ce qui lui manque, ce n'est pas un cerveau.
Le modèle n'est pas le goulot d'étranglement ; le contexte manquant, si
Demandez-vous ce dont un agent a réellement besoin pour livrer un changement sur vos systèmes sans rien casser. Il n'a pas besoin d'être plus intelligent. Il a besoin de savoir ce que signifie « client à risque » dans votre secteur. Il a besoin de savoir lequel des six pas de ce processus de remboursement ne doit jamais être sauté. Il a besoin de savoir pourquoi ce service-là a été construit d'une manière aussi étrange — et que c'était à cause d'un incident du trimestre dernier qui s'est terminé par la décision de ne jamais relancer automatiquement contre cet endpoint.
Rien de tout cela ne vit dans les poids du modèle. Cela vit dans la tête de trois personnes, dans un fil Slack que personne ne retrouvera, dans un Confluence qui n'a pas bougé depuis un an, dans un ticket Jira clos et dans un post-mortem que personne n'a relu. Le modèle le plus puissant de la planète, sans ce contexte, c'est une nouvelle recrue au premier jour, sans onboarding. Donnez-lui le meilleur cerveau du marché : s'il ne sait pas comment marche votre entreprise, il devinera. Et un agent qui devine en production, ce n'est pas de la productivité : c'est de la dette.
Les quatre conditions de McKinsey n'en font, en réalité, qu'une
L'article énumère quatre conditions pour que les agents fonctionnent : une vision métier claire de ce qu'il faut construire, un environnement technique standard avec des frameworks communs et une architecture modulaire, une structure standard du besoin au code pour que les entrées soient prévisibles, et des parties prenantes qui restent engagées sur toute la chaîne de valeur.
Quatre cases. Mais regardez de près : elles pointent toutes vers le même endroit. Ce ne sont pas quatre exigences indépendantes ; ce sont quatre facettes d'un seul substrat. Toutes les quatre visent à rendre le contexte de votre organisation lisible et fiable, au point qu'une machine puisse raisonner dessus. La vision claire, c'est du contexte sur le quoi. L'environnement standard, c'est du contexte sur le comment. La structure du besoin au code, c'est du contexte dans un format que l'agent peut consommer sans l'interpréter. Et les parties prenantes engagées, c'est la garantie que ce contexte ne se désynchronise pas du réel en milieu de semaine. McKinsey vend une liste à cocher ; sur le terrain, c'est une seule chose, et elle a un nom.
Le knowledge graph est la couche de mémoire de l'IA
C'est là que l'article dit la chose vraiment intéressante, et c'est celle à emporter. Les entreprises en tête de course construisent des knowledge graphs qui font office de couche de mémoire d'IA sur tout le cycle de vie logiciel, un par domaine : ils relient les retours clients, les décisions d'architecture consignées, les documents de conception, les tickets, l'activité GitHub, les rapports d'incident et les règles de conformité.
Le mot clé est relier. Un système de RAG sur un wiki — dont j'ai déjà parlé pour celles et ceux qui intègrent des LLM — vous ramène le paragraphe dont les mots collent à votre question. Utile, mais plat. Une vraie couche de mémoire sait autre chose : elle sait que cet incident a déclenché cette décision d'architecture, qui contraint ce service, dont le responsable a écrit cette règle de conformité. La valeur n'est pas dans les nœuds, elle est dans les arêtes. La différence entre les deux, c'est la différence entre un agent qui vous cite le wiki et un agent qui respecte vos cicatrices.
Et c'est exactement la couche dont je soutenais qu'elle était le rempart : le modèle banalise les 80 % faciles, et la différenciation se déplace vers le système qui l'entoure. La mémoire de la façon dont votre entreprise marche vraiment, c'est la partie de ce système qu'aucun fournisseur de modèles ne peut vous vendre, parce qu'il ne l'a pas.
On a déjà encodé du savoir tribal, et on a appelé ça l'infrastructure as code
Si cela vous parle, c'est que ceux d'entre nous qui viennent de l'exploitation ont déjà fait ce geste plusieurs fois. Chaque saut vers l'autonomie, sans exception, a été le même : prendre un savoir qui vivait dans la tête d'un ingénieur senior et l'encoder pour qu'une machine puisse agir dessus.
Les runbooks à la main sont devenus de la remédiation automatique. Les étapes de déploiement que seul un collègue connaissait sont devenues un pipeline de CI/CD. Le « demande à Maria, c'est elle qui sait comment la prod est câblée » est devenu de l'infrastructure as code. Et voici le détail que tout le monde oublie : le pipeline ne s'est pas mis à tourner tout seul parce que les outils sont devenus intelligents. Il s'est mis à tourner tout seul quand on a écrit ce que savait Maria. Des agents qui livrent du logiciel la nuit, c'est exactement cette leçon, un étage au-dessus. L'agent s'exécute sans supervision jusqu'au point précis que son contexte autorise, et pas un pas de plus. Le substrat n'est pas une magie nouvelle ; c'est du savoir tribal, enfin écrit dans une forme qu'une machine peut parcourir.
La livraison 24 heures est la récompense, pas l'objectif
Voilà pourquoi la cadence quotidienne que vend McKinsey est réelle, mais elle vient après le substrat, pas avant. L'exécution nocturne fonctionne aussi loin que la mémoire de l'agent le laisse avancer seul ; passée cette ligne, il s'arrête et attend un humain. La métrique qui compte n'est donc pas « les agents peuvent-ils tourner la nuit », mais jusqu'où l'agent va avant de buter sur une question à laquelle seule une personne peut répondre — et chacun de ces arrêts est un bug de contexte dans votre couche de mémoire, pas une défaillance du modèle.
Ici, laissez-moi concéder le contre-argument fort, car il est bon : « les modèles s'améliorent chaque trimestre, les fenêtres de contexte grandissent — le prochain modèle ne va-t-il pas tout avaler ? » En partie, oui. Une part de l'échafaudage d'aujourd'hui sera absorbée : de meilleurs modèles ont moins besoin qu'on les tienne par la main, et de plus grandes fenêtres avalent plus de documents d'un coup. Mais une fenêtre de contexte n'est pas une mémoire. Coller tout votre wiki dans le prompt ne fait pas que le modèle sache quel pas ne jamais sauter ; ça le fait lire un tas de texte peut-être contradictoire, et deviner. Savoir exige de la curation, de la vérification, de la fraîcheur et de la résolution de conflits : décider laquelle de deux sources qui se contredisent est la vérité valable aujourd'hui. C'est du jugement, c'est un humain qui le fait, et c'est un travail d'ingénierie permanent. Le modèle est loué, et identique pour le concurrent d'en face. La mémoire curée de la façon dont votre entreprise marche vraiment, c'est la partie que personne ne peut louer.
Ce que je ferais ce trimestre si j'étais votre CTO
Cinq paris concrets, parce qu'un diagnostic sans action n'est qu'une jolie opinion :
- Repérez où vit vraiment votre contexte. Avant d'acheter la moindre « usine à agents », faites l'inventaire inconfortable : quelle part du savoir dont un agent aurait besoin pour livrer du code ne vit que dans des têtes, des fils Slack et un wiki périmé ? Cette réponse, c'est votre goulot d'étranglement. Pas le modèle.
- Construisez la mémoire d'UN domaine, pas de toute l'entreprise. Le knowledge graph de tout le cycle de vie d'un coup, c'est un projet qui meurt en comité. Choisissez un domaine avec une vraie douleur, reliez-en les décisions consignées, les tickets, les incidents et les règles de conformité, et faites raisonner un agent dessus. Apprenez là avant de passer à l'échelle.
- Standardisez le chemin du besoin au code. C'est la condition de McKinsey qui fait vraiment bouger l'aiguille. Si chaque fonctionnalité arrive dans un format différent, l'agent devine ; si elle arrive dans une structure prévisible, il exécute. Des entrées reproductibles avant des sorties autonomes.
- Intégrez la conformité dans la mémoire, pas à la fin. Les règles de risque, juridiques et de sécurité doivent être des nœuds que l'agent lit pendant qu'il construit, pas une porte que quelqu'un ouvre une fois tout terminé. Un contrôle qui vit dans le graphe améliore la traçabilité et la complétude ; un contrôle qui vit dans un PDF est un goulot d'étranglement à visage humain.
- Mesurez l'autonomie à la distance que l'agent parcourt seul. Oubliez le « pourcentage de code écrit par l'IA ». La métrique honnête, c'est le nombre de pas qu'un agent enchaîne avant d'avoir besoin d'un humain — et traiter chaque arrêt comme un bug de contexte à corriger dans le substrat, pas comme un plafond du modèle.
La ligne que je défends est toujours la même, et ici l'IA l'illustre de la façon la plus littérale que j'aie jamais vue : elle ne remplace pas l'ingénieur, elle le démultiplie. Quelqu'un doit décider laquelle de deux sources contradictoires est la vérité, quel pas ne se saute jamais, quand un savoir a péri. Ce travail — construire et entretenir la mémoire de la façon dont votre entreprise marche vraiment — ce n'est pas le modèle qui le fait. C'est un ingénieur avec du jugement. Et plus vous voulez vos agents autonomes, plus il vous en faut, pas moins.
McKinsey vend la destination : des agents qui livrent du logiciel pendant que vous dormez. Ils ont raison sur le fait que c'est possible. Ce que la diapositive vous épargne, c'est que le moteur bon marché et interchangeable n'a jamais été le problème. Le problème, comme toujours, c'est toute la voiture autour — et cette fois, la pièce la plus difficile à construire s'appelle mémoire.
Vous essayez de faire passer vos agents de la démo à la production, et ce qui se désynchronise, c'est le contexte, pas le modèle ? Parlez à un CTO pour monter le squad nearshore qui vous construit la couche de mémoire, pas seulement celui qui branche l'agent.
