Quand Votre Agent Quitte le Bâtiment
Trois Primitifs d'Infrastructure que Personne d'Autre ne Construit Encore
La semaine dernière, Anthropic a accidentellement publié l'intégralité du code source de Claude Code. 1 902 fichiers. Plus de 512 000 lignes. L'architecture complète de l'un des systèmes d'IA agentique les plus commercialement réussis jamais déployés, exposée parce que quelqu'un a oublié d'exclure une source map d'un package npm. Bien joué ! Une erreur simple, aux conséquences considérables.
Internet a catalogué les fonctionnalités cachées. Le Tamagotchi. Le mode vocal non publié. Les 44 drapeaux de fonctionnalités. Voilà qui est intéressant pendant cinq minutes environ.
Ce qui l'est bien plus longtemps, c'est ce que Nate B. Jones a découvert en cartographiant l'infrastructure sous-jacente aux fonctionnalités. Nate dirige l'une des newsletters de stratégie IA les plus respectées du secteur, avec un historique éprouvé de traduction des développements techniques bruts en cadres réellement exploitables par les responsables d'ingénierie et les dirigeants. Son analyse de la fuite du code Claude a identifié 12 primitives d'infrastructure qui déterminent si un système agentique fonctionne réellement en production : persistance des sessions, pipelines de permissions, gestion du budget de tokens, registres d'outils, reprise après incident, harnais de vérification, et bien d'autres.
Sa conclusion : l'appel LLM ne représente peut-être que 20 % de ce qui fait fonctionner un agent. Les 80 % restants, c'est la plomberie.
Il a raison. Et nous construisons activement cette plomberie ici, chez PAICE. Mais lorsque nous avons confronté ses 12 primitives à ce que nous avons déployé, quelque chose nous a sauté aux yeux.
Chaque primitive du cadre est interne à l'agent. Ce qui se passe à l'intérieur des propres frontières de l'agent : ses propres sessions, ses propres permissions, son propre budget de tokens, ses propres outils. Aucune d'entre elles ne traite de ce qui se passe lorsque l'agent interagit avec le monde extérieur à lui-même.
Ce n'est pas une critique du cadre de Nate. C'est simplement le chapitre suivant.
Les 12 primitives sont nécessaires. Elles ne sont pas suffisantes.
Soyons clairs sur ce que le cadre de Nate couvre, et couvre bien : si votre agent ne peut pas faire persister les sessions après un crash, ne peut pas appliquer des niveaux de permission sur ses propres outils, ne peut pas suivre sa propre consommation de tokens avant d'effectuer un appel API, et ne peut pas vérifier ses propres résultats par rapport à des tests invariants, vous n'avez pas un système de production. Vous avez une démo. Les 12 primitives constituent l'infrastructure minimale viable pour un agent opérationnel.
Mais les agents n'existent pas en vase clos. Ils appellent des API externes. Ils opèrent dans plusieurs juridictions réglementaires. Ils travaillent aux côtés d'humains qui ne leur accordent pas toujours toute leur attention. L'infrastructure qui régit ces interactions ne réside pas à l'intérieur de l'agent. Elle réside entre l'agent et tout ce qu'il touche.
Nous avons identifié trois primitives qui comblent cette lacune. Toutes trois sont déployées, en open source, et fonctionnent en production sous PAICE.work PBC.
Frontières de permissions inter-services
Le cadre de Nate décrit une pile de sécurité à 18 modules pour un seul outil d'exécution shell au sein de Claude Code. Défense en profondeur : patterns de commandes pré-approuvés, avertissements pour les commandes destructives, vérifications de sécurité spécifiques à git, détermination du bac à sable. Chaque module peut bloquer l'exécution de manière indépendante.
C'est rigoureux. Et c'est également limité à l'exécution des propres outils de l'agent. Que se passe-t-il lorsque l'agent appelle un service externe et atteint une limite de débit ? Lorsqu'il est bloqué ? Lorsqu'il rencontre une limite de capacité que le service n'a pas documentée ?
À l'heure actuelle, les agents échouent silencieusement aux frontières des services. Le service renvoie un 429 ou un 403, l'agent réessaie ou hallucine pour contourner l'obstacle, et l'utilisateur se demande pourquoi le résultat est incorrect. Il n'existe pas de méthode standard permettant à un service de communiquer ses limites à un agent, ni de méthode standard permettant à un agent de comprendre et de respecter ces limites de manière appropriée.
Graceful Boundaries est notre spécification publiée qui répond à ce besoin. Elle définit comment les services communiquent leurs limites opérationnelles aussi bien aux humains qu'aux agents, avec six niveaux de conformité et 131 tests validés. Elle couvre la communication proactive des limites (des en-têtes qui informent les agents de ce qui est disponible avant qu'ils n'atteignent un blocage), les réponses de refus structurées (des explications lisibles par machine expliquant pourquoi une requête a été refusée) et les mécanismes de découverte (permettant aux agents de comprendre les limites d'un service avant leur première requête). Gratuit et open source, comme tout standard digne de ce nom devrait l'être.
Siteline en est l'implémentation de référence. Il analyse les sites web et les API pour évaluer leur conformité à Graceful Boundaries et note leur degré de préparation aux agents à l'aide du référentiel SNAP. Pensez-y comme au pattern du médecin décrit par Nate, externalisé : au lieu que votre agent effectue un bilan de santé sur lui-même, Siteline effectue un bilan de santé sur les services dont dépend votre agent. Il ne s'agit pas de SEO, mais de savoir dans quelle mesure votre site web est adapté aux agents. Également gratuit.
La pile de permissions interne vous garantit une exécution sécurisée des outils. Les frontières inter-services vous garantissent des interactions sécurisées avec tout ce qui se trouve en dehors du propre processus de l'agent.
Contexte réglementaire avec traçabilité de provenance
L'une des primitives les plus importantes qu'identifie Nate est l'assemblage de contexte avec traçabilité de provenance : chaque élément de contexte récupéré par votre agent doit comporter des métadonnées indiquant d'où il provient, quand il a été généré et dans quelle mesure il est fiable. Sans ces métadonnées, le contexte récupéré devient une nouvelle surface d'injection de prompt.
Le cadre décrit cela comme une problématique de mémoire interne. Mais pour les agents opérant dans des secteurs réglementés, le contexte le plus critique n'est pas la mémoire interne. C'est la vérité juridique externe vérifiée.
Lorsqu'un agent doit déterminer s'il peut traiter des données personnelles dans l'UE, ou quelles obligations de divulgation s'appliquent aux conseils financiers générés par IA à New York, la réponse ne peut pas provenir d'un résumé halluciné d'une réglementation que le modèle a rencontrée lors de son entraînement. Elle doit provenir d'un instrument juridique vérifié, sourcé et daté, avec des métadonnées claires sur la juridiction et l'autorité.
EveryAILaw.com est un outil de suivi réglementaire centré sur les obligations, couvrant 51 instruments dans 31 juridictions, avec plus de 200 juridictions mondiales explorées. Le modèle de données traite les obligations comme des entités de premier ordre (et non les lois), avec des champs de provenance intégrés dans la structure : juridiction, date d'entrée en vigueur, autorité source, historique des amendements et statut d'application. L'ensemble du jeu de données est accessible via un serveur MCP, ce qui signifie que tout agent peut l'interroger par programme et recevoir des réponses structurées et sourcées.
La distinction entre une approche centrée sur les lois et une approche centrée sur les obligations est ici déterminante. Un outil centré sur les lois vous dit « l'AI Act européen existe ». Un outil centré sur les obligations vous dit « si vous déployez un système d'IA à haut risque dans l'UE, vous devez effectuer une évaluation de conformité en vertu de l'article 43, applicable à partir d'août 2025, appliquée par les autorités nationales de surveillance du marché ». C'est la différence entre un document de référence et un outil d'aide à la décision.
Pour le portefeuille PAICE en particulier, cela alimente nos prochaines variantes d'évaluation spécifiques aux juridictions. Une évaluation PAICE pour un conseiller financier dans l'UE fait remonter un contexte réglementaire différent de celui d'un prestataire de soins de santé en Californie. Les métadonnées de provenance rendent cela possible sans avoir à coder en dur la logique de juridiction dans le moteur d'évaluation. Car ces réglementations évoluent fréquemment, et continueront de le faire.
Harnais de vérification humaine
Le harnais de vérification de Nate est la huitième primitive de son cadre. Il définit des tests invariants qui détectent les régressions : les outils destructifs requièrent toujours une approbation, les sorties structurées sont validées par rapport au schéma, les outils refusés ne s'exécutent jamais, l'épuisement du budget produit un arrêt gracieux. Ces tests vérifient que l'agent fonctionne correctement.
Personne ne construit l'équivalent pour l'humain dans la boucle.
C'est la lacune qu'PAICE existe pour combler. Tout système d'agent impliquant une supervision humaine (et dans les secteurs réglementés, c'est le cas de tous) repose sur l'hypothèse que l'humain exerce réellement cette supervision. Qu'il détecte les erreurs. Qu'il remet en question les résultats trop confiants. Qu'il vérifie les affirmations avant d'agir en conséquence. Mais cette hypothèse est non testée dans presque tous les systèmes déployés.
PAICE (People + AI Collaboration Effectiveness) mesure cela par l'observation comportementale. Il ne s'agit pas d'un test de connaissances ni d'une auto-évaluation. Il observe comment les individus réagissent aux erreurs de l'IA, à la surconfiance et aux hallucinations lors d'une vraie conversation, et produit un score sur cinq dimensions : Performance, Accountability, Integrity, Collaboration et Evolution.
La notation suit une hiérarchie des preuves : détecter les erreurs injectées l'emporte toujours sur la fluidité conversationnelle. Un professionnel laconique qui détecte chaque erreur plantée obtient un meilleur score qu'un communicant brillant qui les manque. L'évaluation mesure ce que les personnes font, et non ce qu'elles disent qu'elles feraient.
Pour les secteurs réglementés, ce n'est pas un luxe. Si un responsable de la conformité valide mécaniquement des conclusions d'audit générées par IA sans les vérifier, la pile de permissions à 18 modules à l'intérieur de l'agent n'a aucune importance. L'humain dans la boucle est la couche de vérification finale, et à l'heure actuelle, personne ne teste si cette couche fonctionne.
Ces trois primitives ne sont pas optionnelles pour les secteurs réglementés
Si vous construisez des agents pour des produits grand public, les réseaux sociaux ou des outils de productivité interne, les 12 primitives internes peuvent suffire. Vos agents opèrent dans des environnements où les échecs silencieux sont gênants mais pas catastrophiques.
Si vous déployez des agents dans la santé, les services financiers, le juridique, l'assurance, la cybersécurité ou le secteur public, les trois primitives externes ne sont pas optionnelles. Les professionnels de la GRC doivent vérifier que les agents respectent les frontières des services externes. Les responsables de la conformité ont besoin d'un contexte réglementaire avec traçabilité de provenance, et non de résumés juridiques hallucinés. Les RSSI ont besoin de preuves que les humains au sein de leur organisation exercent réellement leur rôle de supervision, et ne se contentent pas d'occuper une place dans la boucle.
Les 12 primitives internes vous amènent jusqu'en production. Ces trois-ci vous amènent jusqu'en production dans des secteurs où les erreurs ont des conséquences professionnelles.
Toutes trois sont déployées. Toutes trois sont gratuites pour les particuliers. Toutes trois sont interconnectées via MCP, ce qui signifie qu'elles se combinent en un système plutôt que d'exister comme des outils isolés. Et toutes trois sont disponibles dès aujourd'hui sous PAICE.work PBC.
Vous souhaitez évaluer l'efficacité avec laquelle votre équipe collabore avec l'IA ? Découvrez PAICE pour les organisations ou effectuez une évaluation individuelle pour en avoir un aperçu concret.
Participez :
- Effectuer l'évaluation (gratuit, toujours)
- Explorer nos offres Baseline (pour les organisations)
- Lire le livre blanc (cadre complet)
- Nous contacter au sujet de vos besoins spécifiques
Lectures recommandées
📖 Comprendre l'écosystème PAICE :
- Filling the Missing Trust Layer – Pourquoi nous avons regroupé 10 projets sous PAICE.work PBC
- The Visibility Gap – Ce que les organisations ne voient pas de la collaboration avec l'IA
📖 Intégrer la vérification dans la pratique :
- Verification Workflows That Actually Work – Approches pratiques de la vérification People+AI
- AI Governance: The Clock Is Ticking – Pourquoi l'infrastructure de gouvernance ne peut pas attendre
Curieux mais pressé ?
Faites le PAICE Pulse en 3 minutes — une vérification rapide qui cartographie votre perception de votre posture de collaboration IA. Aucune connexion requise.