Il y a onze ans, j'ai démissionné. Pas par lassitude : par lucidité. Je voyais le DevOps, le 12-factor, le cloud et la conteneurisation en train de dissoudre le problème que je résolvais. La distance devenait bon marché à franchir. La proximité — co-localisation, you build it you run it, le product owner dans la pièce — gagnait la guerre. Mon métier, le type qu'on envoie recréer du lien par-dessus la frontière, devenait une relique. J'ai eu raison de partir. Je commence à croire que j'ai eu tort de croire que ce muscle était mort.

Le Covid a été le premier rappel. Du jour au lendemain, des organisations entières se sont remises à gérer des équipes opaques, distantes, pilotées par instruments — et j'ai senti le vieux réflexe se rallumer, avant que la plupart ne comprennent ce qui se passait. La distance que l'agilité croyait avoir tuée n'était pas morte. Elle était cachée par le bureau partagé.

Les agents sont le second rappel, et le plus brutal. Déployer une flotte d'agents, c'est rétablir exactement la distance que j'ai passé ma carrière à franchir — sauf qu'il n'y a plus personne de l'autre côté à qui rendre visite. On ne prend pas un café avec un agent. On n'aligne pas une flotte d'agents par un dîner d'équipe. La thèse de ce billet, posée crûment : l'agilité a si bien gagné la guerre de la proximité qu'elle a détruit le muscle qui gérait la distance — et nous redéployons aujourd'hui la distance sans l'outil qui servait à la refermer. La cohésion ne se déploie pas.

Oubliez l'offshore que vous croyez connaître​

Avant d'aller plus loin, il faut tuer une lecture paresseuse, parce que c'est elle qui va vous faire décrocher. Quand j'écris « offshore », vous entendez probablement « main-d'œuvre pas chère, loin, pour faire baisser le coût ». C'est la version décorative. Ce n'est pas celle qui est utile ici, et ce n'est même pas celle qui a fait vivre ou mourir les centres de livraison.

Ce que l'offshore a vraiment produit, c'est une machinerie sociale : l'ensemble des rituels, des gabarits, des gestes qu'on a inventés pour collaborer à travers une frontière opaque avec quelqu'un qu'on ne voyait pas travailler. Le vrai problème n'a jamais été le coût horaire. Ça, c'était la ligne du business case. Le vrai problème, celui qui faisait échouer un centre à vingt millions pendant qu'un autre tournait, c'était la confiance, l'alignement et le transfert de savoir par-dessus une distance. Le coût était l'argument de vente ; la distance était le métier.

Et c'est précisément cette distinction que l'agilité a brouillée en gagnant. En supprimant la distance physique — squads co-localisées, QA embarquée, livraison continue — elle a rendu la machinerie sociale invisible, puis superflue, puis oubliée. On n'a pas décidé que gérer la distance était inutile. On a simplement arrêté d'avoir de la distance à gérer. Le savoir-faire ne s'est pas périmé : il a perdu son terrain d'exercice. Pendant dix ans, personne n'a eu besoin de prendre l'avion pour recréer du lien, parce que tout le monde était déjà dans la même pièce — ou à un appel vidéo de l'être.

Déployer des agents, c'est rouvrir ce terrain. Vous récupérez d'un coup une main-d'œuvre industrialisée, opaque, « de l'autre côté » — et vous découvrez que les gestes pour la gérer, vous les avez désappris. Pire : certains ne se rejouent plus du tout. C'est là que commence l'inventaire — ce qui se transfère, ce qui s'invente, et le seul réflexe qui, lui, vous trahira.

Ce qui se transfère​

Deux disciplines offshore se rejouent presque à l'identique sur une flotte d'agents.

La confiance à travers l'opacité. Je n'ai jamais regardé un développeur offshore coder. J'ai construit des rituels pour fabriquer une confiance que je ne pouvais pas observer directement : critères d'acceptation, revues de jalon, portes de qualité, reporting. Exactement ce que vous rebâtissez aujourd'hui autour d'un agent — eval gates, revue humaine, rituel d'approbation. Le problème est identique : produire de la confiance sans voir le travail. Le réflexe offshore se transfère sans retouche, et il arrive déjà entraîné.

Le transfert de savoir vers la boîte. Le SOW qu'on écrivait jusqu'à la douleur, le runbook, la spec « si détaillée qu'elle fait mal » — c'est votre contexte, votre prompt, votre spec d'agent, réincarnés. Même discipline, et surtout même mode d'échec : sous-spécifiez, et la boîte produit quelque chose de plausible et de faux, exactement comme le centre offshore livrait au pied de la lettre une consigne mal écrite. Celui qui a souffert d'un SOW bâclé sait déjà pourquoi votre agent part en vrille — et il sait que la réponse n'est pas « un meilleur modèle », c'est « une meilleure consigne ».

Ce qui s'invente​

Ici, le transfert s'arrête net, et c'est le cœur de ce que j'ai à dire.

La partie de mon métier qui n'avait rien à voir avec le pilotage, c'était la cohésion : le déplacement, le dîner d'équipe, la présence physique qui faisait que deux équipes séparées par six mille kilomètres se sentaient appartenir au même projet. Ce geste-là n'a aucun équivalent agent. On ne prend pas l'avion pour aligner une flotte. Il n'y a personne à qui serrer la main, personne à mettre à l'aise, personne dont la déférence culturelle masque un désaccord qu'un bon dîner ferait sortir.

Ce qui veut dire que la cohésion, côté agents, ne se transfère pas : elle se réinvente, et elle se déplace. Elle ne vit plus entre vous et la boîte — il n'y a rien dans la boîte à aligner. Elle vit entre les humains au contact de la boîte. Vos développeurs, votre QA, vos opérateurs qui, chacun, promptent, corrigent, approuvent un peu différemment. La dérive que je combattais jadis — douze donneurs d'ordre onshore, douze consignes subtilement différentes à un seul centre — se rejoue intégralement, mais entièrement du côté onshore. La frontière culturelle n'est plus entre ici et là-bas. Elle est entre vous et votre collègue d'à côté, médiée par un agent qui amplifie vos divergences au lieu de les absorber. Le muscle à réinventer, ce n'est pas « gouverner l'agent ». C'est gouverner la cohérence des humains qui le tiennent — sans l'outil qui marchait, la proximité, puisqu'elle est déjà là et n'a rien résolu.

Ce qui vous trahit​

Reste un réflexe, un seul, et c'est le plus dangereux parce qu'il est juste assez proche pour sembler transférable.

L'offshore m'a entraîné au temps dilaté. La boucle de correction coûtait cher et traînait : décalage horaire, aller-retour nocturne, perte du feedback en temps réel. D'où le réflexe : sur-spécifier en amont, batcher le feedback, parce qu'une correction tardive est hors de prix. Vingt ans de delivery distribué ont gravé ce réflexe dans une génération de managers.

L'agent inverse tout. La boucle est effondrée : la correction est gratuite et instantanée. Le manager qui rejoue le réflexe offshore va sur-spécifier et sous-itérer — écrire le SOW géant, lancer, attendre, inspecter — là où l'économie de l'agent récompense l'exact inverse : spec mince, boucle rapide, correction dans l'instant. Et l'ironie se referme : le temps effondré, c'est précisément le réflexe que l'agilité m'a vendu il y a onze ans. Celui pour lequel j'ai démissionné. La synthèse que personne ne détient encore, c'est une gouvernance de la confiance façon offshore qui tourne à la cadence de l'agilité — le muscle de la distance, mais câblé sur la boucle courte. Ni le vétéran offshore ni l'agiliste pur ne l'ont : le premier a la gouvernance mais le mauvais tempo, le second a le tempo mais a oublié la gouvernance.

Le poste que nous avons supprimé​

Regardez votre organigramme. L'équipe plateforme possède la tuyauterie. L'équipe data possède les modèles. Qui possède la cohérence des humains au contact de la boîte — la dérive entre dix opérateurs, l'alignement des consignes, la confiance qu'on ne peut pas observer ? Personne. La case est vide.

Elle n'a pas toujours été vide. Elle portait un nom : le delivery manager, le responsable de la transition de services, le type qu'on envoyait recréer du lien par-dessus la frontière. L'agilité a supprimé ce poste parce qu'elle avait supprimé la frontière — et elle a eu raison, tant que la frontière restait supprimée. Sauf qu'on vient de la rouvrir. Nous avons effacé le rôle exactement au moment où il redevenait porteur, et nous confions aujourd'hui la partie la plus difficile — coordonner l'opacité — à l'équipe la moins entraînée pour ça, en croyant que c'est un problème d'outillage.

Alors voici le pari, daté, que vous pourrez me rejeter à la figure dans dix-huit mois : les équipes qui réussiront le déploiement d'agents à l'échelle ne seront pas celles qui auront la meilleure plateforme, mais celles qui auront reconstitué le muscle de la distance — et elles iront le chercher chez des gens que l'agilité avait déclarés obsolètes. Pas pour leur plateforme. Pour leur cicatrice.

Je suis parti il y a onze ans convaincu que ce métier était fini. Je commence à ranger mes certitudes. On peut déployer une flotte en une après-midi ; on ne déploie pas la confiance qui la tient. Celle-là, il faut encore aller la chercher — et il n'y a plus d'avion à prendre. La cohésion ne se déploie pas. C'est tout le problème, et c'est le vôtre maintenant.

La réponse courte : elle converge avec la CNCF et le platform engineering sur presque toutes les frontières, elle diverge sur un point que j'assume — et elle bute sur une distinction que peu de gens font explicitement, alors qu'elle décide de tout : l'agent qu'on produit n'est pas l'agent qui produit. C'est la thèse de ce billet. Le reste est l'étayage.

La convergence : personne ne dessine les mêmes couches, tout le monde décrit les mêmes tensions​

Première surprise en confrontant la carte aux sources : les modèles en couches abondent, mais aucun ne fait autorité au sens strict.

Les documents qui font autorité ne dessinent pas de couches. Le Platforms White Paper de la CNCF liste des capacités, pas des strates. Gartner raisonne en plans de supervision et va jusqu'à écrire que les modèles de référence statiques sont inutiles face à des agents qui bougent à la nanoseconde — position frontalement opposée à l'exercice cartographique. L'autorité existe, mais elle refuse de faire la carte.

Les modèles qui dessinent des couches ne font pas autorité : ils viennent d'analystes indépendants et de blogs de fournisseurs. AIMultiple propose sept couches aussi, avec une lecture moat/commoditisation proche de mon tableau d'achat — mais empile la gouvernance en couche 7 au lieu de la traiter en transverse. Le stack Letta/a16z, repris par O'Reilly, tient en cinq couches orientées construction d'un agent. Seul Catio partage mon parti pris : séparer les composants (perception, raisonnement, mémoire, action) des plans transverses (orchestration, observabilité, sécurité, gouvernance).

Le découpage exact varie donc d'une carte à l'autre. Ce qui ne varie pas, ce sont les tensions décrites : accès aux modèles à centraliser, protocoles à standardiser, état à gérer, coût à borner, gouvernance à rendre omniprésente. Ma carte ne découvre rien ; elle range ces tensions dans un ordre défendable.

Le platform engineering nomme l'hypothèse qui casse​

Le déplacement le plus utile vient d'une discipline plus ancienne. Le Platforms White Paper pose deux principes qui s'appliquent à ma carte sans retouche : la plateforme interne est un produit, et on construit la couche la plus mince possible au-dessus des implémentations managées. Traduit : couches 1, 2 et 5 s'achètent, 3 se construit, le reste doit rester remplaçable.

Puis, dans « Platform engineering for the agentic enterprise » (juillet 2026), la CNCF nomme l'hypothèse implicite de dix ans d'Internal Developer Platforms : le consommateur de la plateforme est un développeur humain. L'agent casse cette hypothèse. Il provisionne, déploie, investigue des incidents, déclenche des workflows. Il devient un consommateur au même titre, avec une exigence supplémentaire : identité propre, permissions restreintes, piste d'audit. La conclusion est explicite — pas de plateforme séparée pour l'IA, mais une extension de la plateforme existante.

Deux conséquences pour ma carte :

• La couche 7 est plus large que je ne l'avais dit. Portail, CLI, GitOps et serveur MCP sont quatre surfaces de la même plateforme. Si elles ne partagent pas le même modèle de gouvernance, vous n'avez pas une plateforme avec quatre surfaces — vous en avez deux.
• Le contexte devient une capacité, pas un accessoire. Topologie, propriété, dépendances, historique de déploiement : l'agent qui diagnostique un échec a besoin de savoir qui possède quoi, pas seulement de retrouver un document. C'est plus exigeant que le RAG de la couche 5.

Les standards durcissent, dans le sens de la carte​

Côté normalisation, trois signaux datés confirment les tendances que la carte annonçait :

• Couche 1 — la conformité arrive. Le Kubernetes AI Conformance Program, lancé en novembre 2025, définit un socle minimal pour exécuter des charges IA. La révision de mars 2026 a durci les exigences (codifiées en Kubernetes AI Requirements) et fait passer les plateformes certifiées de 18 à 31. Une couche qui se certifie est une couche qui se banalise : ma maturité « élevée » est confirmée, et le risque s'y déplace vers le gateway plutôt que vers le runtime.
• Couches 4 et 6 — la gouvernance des protocoles change le calcul du lock-in. MCP a été donné à l'Agentic AI Foundation sous Linux Foundation en décembre 2025, rejoint par A2A en août 2026. Mon « faible si protocole standard » n'est plus un pari : les deux protocoles sont sous gouvernance neutre. Ce qui reste ouvert, c'est la couche 6 elle-même — aucun standard ne décrit encore comment orchestrer des agents, seulement comment ils se parlent.
• Transverses A et B — le travail est déjà cadré. Le document Cloud native agentic standards (CNCF AI TCG, mars 2026) ouvre quatre chantiers : communication, observabilité, gouvernance, sécurité. Deux points à retenir tels quels. L'identité de l'agent n'est pas celle de l'utilisateur : dès qu'un agent agit hors session ou au-delà du périmètre de son commanditaire, il lui faut une identité de charge de travail propre (SPIFFE/SPIRE, comptes de service scopés, jetons courts), sinon l'audit ne veut rien dire. Et l'observabilité agentique n'est pas l'observabilité applicative : tokens, coût d'inférence, durée d'exécution, trajectoires — les conventions sémantiques GenAI d'OpenTelemetry donnent déjà de quoi instrumenter.

La divergence que j'assume : paroi, pas couche fondamentale​

Sur un point, je ne suis pas la CNCF. Elle raisonne depuis Kubernetes et traite la gouvernance comme une couche fondamentale obligatoire — sans elle, rien ne démarre. Ma carte en fait une paroi transverse.

La nuance n'est pas cosmétique. Une couche fondamentale est en dessous : on la pose, puis on empile. Une paroi longe toute la hauteur : elle s'applique à chaque couche, de l'inférence à l'interface. Traiter la gouvernance comme un socle, c'est risquer de croire qu'une fois posée, elle est acquise. La traiter comme une paroi, c'est se rappeler qu'une permission gouverne l'appel d'outil (couche 4) autant que la surface d'interface (couche 7), et qu'aucune couche n'en est exemptée.

Leur cadrage est plus strict que le mien — « rien ne démarre sans gouvernance » est une bonne règle. Mais il naît d'un contexte Kubernetes où le socle est littéral. Hors de ce contexte, la paroi décrit mieux la réalité : la gouvernance n'est pas une étape, c'est une exigence permanente.

Le cadre de fournisseur : Platform Engineering 2.0​

Un troisième corpus circule, et il demande une précaution de lecture. Platform Engineering 2.0 (juin 2026) est un cadre directionnel commandité par Broadcom, co-écrit avec VMware. Ni standard, ni certification : Moor Insights le formule sans détour, c'est un argument de fournisseur, en partie prospectif, dont l'implémentation proposée se trouve vendre de l'infrastructure. Ses cinq piliers restent largement indépendants du produit — mais on ne les lit pas comme un document de fondation neutre.

Ce sont d'ailleurs des piliers, pas des couches. Les versions qui vous les présentent empilés en stack ont reconstruit le modèle. Deux de ces piliers corrigent ma carte :

• FinOps embarqué. Dans mon billet précédent, « la facture explose » était attribuée à l'absence de mesure par appel en couche 1. C'est vrai mais incomplet. L'outillage de coût actuel est rétrospectif : il dit ce que vous avez dépensé après. Le pilier propose de faire apparaître le coût au moment du provisionnement, avec ses alternatives. Mesurer ne suffit pas ; il faut arbitrer avant. La couche 1 n'était que la moitié de la réponse.
• Sécurité « shift-down ». Le shift-left n'a pas échoué, mais la surface d'attaque agentique — injection de prompt, fuite par inférence, exécution non relue — est un problème de runtime qu'un scan de pipeline ne voit pas. D'où l'isolation descendue dans le substrat : microVM et sandbox (Firecracker, gVisor, Kata Containers) plutôt qu'un conteneur partagé, dès que la couche 4 exécute du code que personne n'a lu.

La distinction que personne ne fait : produire un agent, produire avec un agent​

C'est ici que la confrontation devient vraiment utile. À côté de PE 2.0 s'est installée la catégorie des agentic development platforms (ADP), à laquelle Forrester consacre un vendor landscape depuis le troisième trimestre 2026 : des plateformes où humains et agents développent côte à côte.

Ce n'est pas l'objet de ma carte. Et pourtant les deux portent le même adjectif — « agentique ». Deux plateformes différentes, un seul mot :

• L'agent comme producteur (ADP, PE 2.0) : l'agent écrit le logiciel. Le goulot se déplace de l'écriture vers la mise en production — PE 2.0 avance des volumes de code multipliés par deux à dix. La plateforme doit absorber un débit de PR, de revues et d'environnements éphémères qu'elle n'a jamais eu à encaisser.
• L'agent comme produit (ma carte) : l'agent est le logiciel livré. Ce qui compte devient la mémoire, la reprise après compaction, la coordination.

Les deux partagent leur socle — couches 1 et 2 — et leurs deux parois, puis divergent franchement. Aucune couche de livraison à haut débit n'apparaît dans ma carte, et c'est délibéré : elle relève du monde producteur. Symétriquement, la couche 5 (mémoire, connaissance) est quasi absente des modèles ADP, et c'est cohérent — un agent qui produit du code n'a pas besoin de mémoire persistante ; un agent qu'on met en production, si.

Cette distinction explique la moitié des malentendus de réunion. « On va mettre un agent là-dessus » ne désigne pas la même plateforme selon qui parle : l'un pense à un copilote qui accélère l'équipe, l'autre à un service autonome en production. Mêmes mots, budgets, risques et propriétaires différents.

Ce que la confrontation aura servi​

Ma carte n'en sort ni invalidée ni sacralisée. Elle converge avec l'écosystème là où ça compte, diverge sur la gouvernance-paroi pour de bonnes raisons, et gagne deux corrections utiles — le coût qui s'arbitre avant, la sécurité qui descend dans le substrat.

Mais le vrai gain est la distinction producteur/produit. Elle ne figure sur aucune des cartes voisines, et c'est elle qui décide si votre prochain « agent » a besoin d'une couche 5 ou d'une couche de livraison à haut débit. Avant de choisir une plateforme, demandez-vous lequel des deux agents vous construisez. Le mot ne le dira pas pour vous.

Dans la même réunion : pour l'un, c'est un appel LLM avec un prompt système. Pour l'autre, c'est un orchestrateur multi-agents avec mémoire persistante et sandbox d'exécution. Personne ne bronche. Tout le monde hoche la tête.

LLM, agent, agentique, mémoire long / moyen / court terme, MCP, RAG, A2A… comment ranger tout ça, que dois-je prioriser : acheter, construire, héberger, louer, distribuer, centraliser ?

D'où cette cartographie : sept couches, deux préoccupations transverses. Pas de classement, pas de fournisseur à te recommander — juste de quoi situer chaque terme et comprendre de quelle couche vient ton prochain problème.

Attention, ce n'est pas un modèle neutre. Deux partis pris le traversent — traiter sécurité et observabilité comme des parois plutôt que comme des couches, et lire la même cartographie de deux façons opposées — et je les assume plus loin. D'autres cartographies existent ; celle-ci a un point de vue.

La cartographie​

Reprenons l'étagère. Sept niveaux empilés, un pour chaque type de jouet : une place par étage, et la règle qui vaut partout — on ne laisse rien traîner par terre. Ranger, ce n'est pas caser au hasard ; c'est savoir de quel étage relève chaque chose.

Sept dalles empilées, donc, et deux parois qui les longent sur toute la hauteur : les préoccupations transverses. Chaque dalle porte ses composants types peints au sol, colorés selon leur nature — brique différenciante à construire, service managé, infrastructure, standard ouvert, surface utilisateur, ou composant encore émergent.

Pourquoi sécurité et observabilité sont transverses et pas des couches à part ? Parce qu'elles ne se glissent pas entre deux strates : elles s'appliquent à chacune. Une permission gouverne aussi bien l'appel d'outil (couche 4) que la surface d'interface (couche 7) ; une trace instrumente aussi bien l'inférence (couche 1) que la coordination multi-agents (couche 6). Les ranger dans une couche, c'est les rétrograder au rang de simple module — et se rendre compte trop tard qu'elles auraient dû être partout. La règle « on ne laisse rien traîner par terre » ne vit pas sur un étage : elle vaut pour tous.

Les sept couches​

Où ça casse​

La cartographie devient vraiment utile quand tu t'en sers comme grille de diagnostic. Une étagère rangée se dérange toute seule dès que personne ne sait plus de quel étage relève quoi — chaque symptôme ci-dessous, c'est un jouet remis au mauvais niveau, ou laissé par terre.

Si plusieurs lignes te parlent, il y a de fortes chances qu'elles ne pointent pas vers le même responsable dans ton organisation. Et c'est souvent ça, le vrai problème.

Deux lectures de la même cartographie​

Si tu portes l'architecture​

Ce que tu cherches à optimiser : la cohérence, une dette maîtrisée, des dépendances lisibles.

• Couche 1 — le gateway, c'est le seul point qui dure. Centraliser l'accès aux modèles derrière une interface unique, ça découple tout le reste du fournisseur. Trois jours de boulot qui t'en épargnent trente.
• Couche 3 — c'est là que se joue le produit. Ce qui te différencie, ce n'est pas le framework d'orchestration, c'est la gestion d'état : reprise après compaction, idempotence des étapes. Le framework, tu le remplaces ; un état mal pensé, tu le paies.
• Couche 4 — MCP transforme « N agents × M outils » en « N + M ». Et le sandboxing arrête d'être négociable dès l'instant où l'agent exécute du code.
• Couche 7 — c'est ton test de maturité. Si la logique agentique sait sur quelle surface elle tourne, chaque nouveau canal devient une réécriture. Découpler le runtime de la surface, c'est exactement ce qui sépare une vraie plateforme d'une démo.
• Transverses — reformule la question. Pas « est-ce que l'agent est sûr ? » mais « quelle est sa pire action possible, et qui l'approuve ? ».

Si tu portes la décision d'achat​

Ce que tu cherches à optimiser : le risque, le coût total, la dépendance, la maturité.

Cinq questions à poser avant de signer quoi que ce soit :

• Est-ce que l'accès aux modèles passe par un gateway standard ?
• Est-ce que les outils passent par un protocole ouvert (MCP) ?
• Est-ce que la mémoire est exportable — et dans quel format ?
• Est-ce que les traces et les coûts s'exportent vers ton observabilité déjà en place ?
• Est-ce que la sécurité et l'audit sont natifs, ou vendus plus tard en add-on ?

Une réponse floue sur l'une des cinq, ça passe. Deux, c'est un pattern.

Ce que cette cartographie ne dit pas​

Ce qu'elle t'apporte est modeste, mais utile : un vocabulaire commun. Le jour où l'architecte dit « c'est un problème de couche 3 » et que l'acheteur comprend pourquoi ça ne se réglera pas en changeant de fournisseur, la cartographie a fait son job. La chambre n'est jamais rangée une fois pour toutes — mais au moins, tout le monde sait enfin de quel étage relève quoi.

Un mot sur les normes, tant qu'on y est. Sous la couche 2, une norme ISO existe déjà : ISO/IEC 23053 décompose l'anatomie d'un système d'apprentissage automatique — modèle, entraînement, inférence, tâche. C'est le dictionnaire normatif de ta couche 2, et du bord de la couche 1. Mais il s'arrête au modèle : la boucle agentique, MCP, la coordination multi-agents, les surfaces (couches 3 à 7) n'ont aucun équivalent ISO. Quant aux deux parois, elles relèvent d'autres normes de la même famille (SC 42) — 42001 pour la gouvernance, 23894 pour le risque — pas de 23053. Autrement dit : la moitié basse de l'étagère a un dictionnaire officiel, la moitié agentique n'en a pas encore. Ce n'est pas un trou dans la cartographie, c'est pourquoi elle est utile.

Reste une question qu'elle ne tranche pas : est-ce qu'elle tient la route face à ce que la CNCF, le platform engineering et les analystes décrivent de leur côté ? Elle converge avec eux sur la plupart des frontières, diverge sur deux points que j'assume — et bute sur une distinction que personne ne fait vraiment : celle entre l'agent qu'on produit et l'agent qui produit. C'est justement le sujet d'un second billet.