Scaler l’agentique : pourquoi l’outillage ne suffit pas, et comment refonder simultanément l’architecture IA et les modes de travail de la DSI

Thèse. L’expérience individuelle des outils agentiques est puissante, mais elle ne se transpose pas mécaniquement à l’échelle d’une DSI. Scaler l’agentique : pourquoi l’outillage ne suffit pas, et comment refonder simultanément l’architecture IA et les modes de travail de la DSILa mise à l’échelle impose une transformation conjointe et indissociable de deux dimensions : l’architecture technique des systèmes IA (hybride, gouvernée, en partie déterministe) et les modes de travail de l’organisation (rôles, coordination, gouvernance collective, indicateurs). Faire l’une sans l’autre amplifie l’entropie au lieu de la réduire.

Introduction — l’écart qui change tout

Quand je travaille seul avec des outils agentiques (raisonnement en boucle, tool calling, planification dynamique), le gain est réel : vitesse, profondeur d’exploration, capacité à itérer. Mais dès que je passe à des exécutions plus larges, avec des mises en production à coordonner, des dépendances partagées et des exigences de gouvernance, un écart structurel apparaît. Ce qui fonctionne très bien individuellement sur quelques itérations ne se traduit pas naturellement en gain collectif. Pire : sans refonte volontaire et contrôle permanent anti-drift et déterministe, l’agentique amplifie les problèmes de coordination au lieu de les résoudre.

Cet écart n’est pas une impression. La littérature récente le documente : les systèmes multi-agents fondés sur des LLM sont non déterministes et sujets à des défaillances silencieuses — dérive comportementale, boucles, détails manquants — qui n’émettent aucun signal d’erreur explicite et restent donc difficiles à détecter (Pathak et al., 2025, arXiv:2511.04032). Ces phénomènes sont marginaux pour un utilisateur isolé en exploration ; ils deviennent systémiques quand plusieurs personnes, plusieurs systèmes et plusieurs cycles de livraison interagissent.

—

1. L’illusion de la généralisation des outils

Beaucoup d’organisations raisonnent ainsi : « Nos développeurs sont plus rapides avec les outils agentiques, donc en les généralisant nous accélérerons toute la DSI. » C’est une illusion, pour une raison simple :

La productivité d’une DSI n’est pas la somme des productivités individuelles. Elle dépend de la capacité du système collectif à livrer de la valeur de manière fiable, sécurisée, traçable et évolutive.

Quand on augmente fortement la capacité de production et de raisonnement individuelle sans renforcer les mécanismes de coordination collective, on crée un déséquilibre. Les individus produisent plus vite et de façon plus exploratoire ; mais le système n’est pas équipé pour absorber, valider, intégrer et gouverner cette production accrue.

Résultat habituel : hausse de la dette technique, des risques, et du temps passé à corriger plutôt qu’à créer.

—

2. Ce que la recherche confirme

Trois familles de travaux convergent et donnent un socle factuel à la thèse :

• Défaillances silencieuses et dérive à l’échelle. Le non-déterminisme des systèmes multi-agents produit des dérives détectables : Pathak et al. (2025) montrent que des approches supervisées (XGBoost) et semi-supervisées (SVDD) atteignent jusqu’à 98 % et 96 % de précision pour détecter ces anomalies de trajectoire. La dérive n’est donc ni une fatalité ni un détail : c’est un objet d’ingénierie mesurable.
• Garde-fous en amont de l’exécution. Intervenir au stade de la planification, avant toute action, est souvent le moyen le plus sûr de prévenir les dommages ; or la plupart des garde-fous existants opèrent en aval (post-exécution), ce qui passe mal à l’échelle (Huang et al., 2025, arXiv:2510.09781 — AuraGen + Safiron).
• Hybridation LLM + symbolique. La planification structurée de type HTN, combinée au LLM, conserve flexibilité et garanties : ChatHTN interleave décompositions symboliques et approximations LLM tout en restant prouvablement correct (Munoz-Avila, Aha & Rizzo, 2025, arXiv:2505.11814). Le cadrage général de la modélisation HTN par LLM est traité par Puerta-Merino et al. (2025, arXiv:2511.18165).
  

Conclusion intermédiaire : la fiabilité de l’agentique est d’abord une propriété architecturale (Nowaczyk, 2025, arXiv:2512.09458), et la sécurité des systèmes d’agents constitue désormais un champ structuré à part entière (Kim et al., 2026, arXiv:2603.11088).

—

3. Premier pilier — l’architecture technique à l’échelle

À l’échelle, on ne peut plus se contenter d’agents autonomes qui raisonnent librement.

Le principe directeur :

L’agent ne doit raisonner que lorsque c’est nécessaire. Tout ce qui peut être fait de façon déterministe, locale et scriptée doit l’être.

Cela ne supprime pas l’intelligence : cela la réserve aux moments où elle apporte vraiment de la valeur (incertitude, planification complexe, contextes nouveaux), et délègue le reste à du code auditable. J’organise les systèmes autour de trois couches encadrées par une couche de gouvernance.

A. Un Control Plane organisationnel. Au-delà des hooks et skills créés individuellement, il faut un plan de contrôle partagé qui définit les politiques codifiées (qui peut faire quoi, sous quelles conditions), les hooks standards de validation et de sécurité, les mécanismes de routage et de fallback, et l’observabilité collective. Il se conçoit, se versionne et se gouverne comme un produit.

B. Des skills locales déterministes. Plutôt qu’un grand nombre de tools ouverts que l’agent choisit librement, on expose un ensemble restreint de skills déterministes : fonctions fortement typées (validation stricte type Pydantic), logique métier encapsulée, moteurs de règles pour les tâches à fort volume et faible variabilité. L’agent décide quand et dans quel ordre les utiliser ; l’exécution, elle, reste rapide, locale et auditable.

C. Des hooks et une détection de dérive systématiques. Pre-tool (vérification des entrées avant action critique), post-output (validation avant exécution réelle), error & drift (déclenchement d’un comportement déterministe — fallback, replanification contrôlée, escalade — dès qu’une déviation est détectée). Ces hooks doivent être standardisés, testés et déployés collectivement, non laissés à l’initiative individuelle.

D. Une planification structurée. Pour les workflows critiques, passer d’une planification purement LLM à une planification structurée (inspirée des HTN) combinée au raisonnement LLM : flexibilité là où elle est utile, traçabilité là où elle est nécessaire.

Bénéfices observés (ordres de grandeur, à mesurer dans chaque contexte) : réduction sensible des coûts d’exécution, meilleure reproductibilité, baisse de la dérive comportementale, auditabilité accrue. Note : les gains chiffrés dépendent fortement du profil de charge et doivent être instrumentés avant d’être communiqués.

—

4. Second pilier — la refonte des modes de travail de la DSI

L’architecture technique seule ne suffit pas. Sans transformation organisationnelle, le Control Plane reste un objet sans propriétaire et les hooks dérivent.

4.1 Nouveaux rôles

4.2 Processus de coordination — l’exemple de la release

Même une release simple devient risquée quand les pratiques ne sont pas alignées. Le passage à l’échelle exige de rendre la coordination et la gestion des vulnérabilités bloquantes et intégrées, et non parallèles.

flowchart LR
    subgraph AV["AVANT — vigilance individuelle"]
        a1[Dev augmente] --> a2[Build local OK]
        a2 --> a3[Merge rapide]
        a3 --> a4[Prod]
        a4 -.->|regressions, secrets exposes,<br/>dependances incompatibles| a5[Correctifs en urgence]
    end

flowchart LR
 
    subgraph AP["APRES — coordination integree"]
        b1[Dev augmente] --> b2[Hooks pre-merge :<br/>secrets, deps, drift]
        b2 --> b3[Tests d'integration<br/>sur plateforme cible]
        b3 --> b4{Gate vulnerabilites<br/>bloquant}
        b4 -->|OK| b5[Revue transversale]
        b5 --> b6[Prod tracable]
        b4 -->|KO| b2
    end

4.3 Gestion des dépendances et des vulnérabilités

Les sprints de mise à jour ne doivent plus être des activités parallèles « sur le papier » mais des étapes bloquantes du cycle de release, avec tests d’intégration sur la plateforme cible (les contraintes de runtime, de bundling et de sécurité d’un edge comme Cloudflare ne se gèrent pas à coup de vigilance individuelle).

4.4 Indicateurs de santé collective

La velocity individuelle et le nombre de releases ne suffisent plus. On mesure la santé du système :

—

5. L’articulation des deux piliers

Les deux dimensions se renforcent mutuellement. C’est cette boucle — et non l’un des deux piliers isolé — qui produit la performance à l’échelle.

flowchart TD
    A[Architecture IA hybride] -->|rend possible| B[Control Plane + hooks + skills deterministes]
    B -->|permet| C[Gouvernance collective reelle]
    C -->|necessite| D[Refonte des roles & processus]
    D -->|soutient| E[Coordination a l'echelle]
    E -->|reduit| F[Entropie & risques]
    F -->|ameliore| G[Performance collective]
    D -->|fait evoluer| A
    G -.->|retro-alimente les indicateurs| C

Sans l’un ou sans l’autre, le système reste fragile : une architecture impeccable sans propriétaire ni processus dérive ; une organisation refondue sans socle technique déterministe gouverne du vide.

6. Deux retours d’expérience

Les secrets. Sur un projet agentique, des clés avaient été intégrées directement dans les outils pour aller vite — derive individuelle courante. Dès l’intervention de plusieurs équipes, ces secrets sont apparus dans le code, les logs et des systèmes de monitoring partagés. La correction a exigé une remise à plat transversale. La solution durable (récupération dynamique via coffre-fort + hooks sécurisés) doit devenir une pratique individuelle : c’est un choix d’architecture et de processus collectif.

Cloudflare et les paquets. La migration d’une partie de l’exécution vers l’edge était fluide en prototypage mono agent. En coordination multi-agent, des dépendances obsolètes ou incompatibles ont provoqué des régressions et des builds cassés. Des sprints de vulnérabilités existaient mais n’étaient pas intégrés de façon bloquante au cycle de release. La solution a combiné architecture (gestion centralisée des dépendances) et refonte du processus de release.

—

7. Cadre pratique de transformation

—

8. Le pont avec la gouvernance et la conformité

Les mécanismes du Control Plane — traçabilité des décisions, observabilité, journalisation des actions critiques, validation en amont — recoupent largement les attentes de gouvernance du risque ICT que connaissent déjà les DSI régulées (traçabilité, maîtrise des prestataires, résilience opérationnelle).

Traiter l’AgentOps comme un prolongement naturel des cadres de gouvernance existants — plutôt que comme un sujet à part — accélère l’adhésion et évite de réinventer des contrôles. Le mapping précis aux exigences réglementaires applicables relève d’une analyse dédiée, propre à chaque organisation.

Conclusion

L’agentique est un levier puissant, mais elle ne transforme pas automatiquement une organisation : sans refonte volontaire, elle augmente la complexité et les risques. Scaler durablement exige de travailler simultanément sur l’architecture technique (Control Plane, hooks, skills déterministes, planification structurée) et sur les modes de travail (rôles, coordination, gouvernance des dépendances, indicateurs).

La question n’est plus « adoptons-nous l’agentique ? », mais : sommes-nous prêts à refonder à la fois notre architecture et notre façon de travailler pour en tirer réellement parti à l’échelle ?

Pour aller plus loin (sources)

• Huang, Y. et al. (2025). Building a Foundational Guardrail for General Agentic Systems via Synthetic Data (AuraGen + Safiron). arXiv:2510.09781 — https://arxiv.org/abs/2510.09781
• Pathak, D. et al. (2025). Detecting Silent Failures in Multi-Agentic AI Trajectories. arXiv:2511.04032 — https://arxiv.org/abs/2511.04032
• Puerta-Merino, I., Núñez-Molina, C. et al. (2025). Towards a General Framework for HTN Modeling with LLMs. arXiv:2511.18165 — https://arxiv.org/abs/2511.18165
• Munoz-Avila, H., Aha, D. W. & Rizzo, P. (2025). ChatHTN: Interleaving Approximate (LLM) and Symbolic HTN Planning. arXiv:2505.11814 — https://arxiv.org/abs/2505.11814
• Nowaczyk, S. (2025). Architectures for Building Agentic AI (chapitre, Springer). arXiv:2512.09458 — https://arxiv.org/abs/2512.09458
• Kim, J. et al. (2026). The Attack and Defense Landscape of Agentic AI: A Comprehensive Survey (USENIX Security 2026). arXiv:2603.11088 — https://arxiv.org/abs/2603.11088
• Fiddler AI (2025). Lessons Learned from Building Agentic Systems — billet d’éditeur (source secondaire).
• Agno (2025). Guardrails for AI Agents — billet d’éditeur (source secondaire).