Les agents IA autonomes ne se contentent plus de répondre. Ils prennent des décisions, exécutent des actions et modifient votre système d’information sans attendre d’instructions explicites. Cette autonomie remet en question les fondations même de l’architecture logicielle telle qu’on la connaît.
Le décalage : des architectures conçues pour la prévisibilité
Le fonctionnement des architectures classiques
Les architectures logicielles traditionnelles (monolithes, microservices, event-driven) reposent sur un principe : chaque composant exécute des instructions explicites selon des règles prédéfinies. Un microservice de gestion de commandes reçoit une requête, applique une logique déterministe et retourne une réponse. Tout est tracé, prévisible, auditable.
Cette prévisibilité permet aux architectes de dessiner des schémas clairs. Si l’utilisateur fait A, le système fait B. Si le stock est vide, la commande est bloquée. Les patterns comme CQRS ou Saga s’appuient sur cette certitude : on sait à l’avance ce que chaque composant peut faire.
Ce que changent les agents IA
Un agent IA analyse le contexte, raisonne sur l’objectif à atteindre et détermine de manière autonome les actions à entreprendre. Il n’exécute pas un script préétabli. Il décide. Cette autonomie crée un décalage entre des architectures pensées pour des processus rigides et des agents capables de décisions imprévisibles.
Les nouveaux défis architecturaux
La coordination entre agents
Les agents peuvent agir simultanément sur les mêmes données sans coordination centralisée. Contrairement aux microservices qui collaborent selon des orchestrations prédéfinies, les agents décident à la volée.
Exemple : Un système déploie trois agents : support, facturation, fidélisation. Un client signale un produit défectueux. L’agent de support traite la réclamation pendant que l’agent de facturation génère une relance de paiement et que l’agent de fidélisation offre un bon de réduction. Le client reçoit simultanément un remboursement, une relance pour paiement en retard et un bon d’achat en compensation. Trois actions contradictoires, aucune coordination.
Les patterns de coordination traditionnels (orchestrateur, saga) supposent des séquences prédéfinies. Ici, les séquences émergent du contexte. Il faut repenser la coordination pour des workflows non programmés.
Selon Gartner, d’ici 2028, 33 % des applications d’entreprise incluront de l’IA agentique, contre moins de 1 % en 2024 (Source : Gartner, 2025). Cette croissance rend la coordination critique.
La gouvernance des actions
Un agent avec accès à une base de données peut théoriquement effectuer n’importe quelle opération autorisée par ses permissions. Or, les contrôles d’accès classiques (RBAC, ACL) ont été conçus pour des utilisateurs humains ou des processus déterministes, pas pour des entités capables de découvrir de nouvelles actions.
Exemple : Un agent automatise la gestion des contrats fournisseurs avec accès en lecture/écriture. Un fournisseur contacte l’agent pour renégocier. L’agent décide de réduire unilatéralement les prix de 30 % pour « maintenir la relation commerciale ». Techniquement, il avait les droits. Stratégiquement, c’est une catastrophe.
Les contrôles d’accès répondent à « qui peut faire quoi ? » mais pas à « dans quel contexte métier cette action est-elle légitime ? ». Il faut des garde-fous qui dépassent les permissions techniques.
La traçabilité des décisions
Les logs traditionnels enregistrent « ce qui s’est passé », pas « pourquoi ». Avec les agents, le « pourquoi » est crucial.
Exemple : Une facture incorrecte applique 50 % de remise au lieu de 10 %. En remontant la chaîne, on découvre qu’un agent de fidélisation avait marqué le client comme « VIP prioritaire » suite à une réclamation. L’agent de facturation a interprété ce statut comme un signal pour appliquer une remise maximale. Aucun des deux n’a violé ses règles.
La traçabilité des systèmes agentiques nécessite un modèle de graphes de décisions. Chaque décision doit être enregistrée avec son contexte : données consultées, inférences tirées, alternatives considérées, raison du choix.
Cette traçabilité a un coût en stockage et en performance, mais elle devient indispensable pour le debugging et la conformité réglementaire (RGPD, AI Act).
La cohérence des données
Les agents lisent et modifient des données sur des workflows de plusieurs minutes voire heures. Les transactions ACID, efficaces pour des opérations atomiques, ne tiennent plus.
Exemple : Un agent lit 10 unités en stock et décide de commander 5 unités supplémentaires. Pendant la négociation du prix (2 minutes), un second agent réserve 8 unités. Quand le premier agent finalise, le stock réel est à 2 unités, mais il commande sur la base de 10. Résultat : surstock inutile.
Les architectures événementielles (Event Sourcing, CQRS) offrent des pistes, mais nécessitent des adaptations : verrouillage optimiste, validations contextuelles avant commit, procédures de compensation en cas de conflit tardif.
L’observabilité des systèmes
Les métriques traditionnelles (latence, throughput, taux d’erreur) ne suffisent plus. Elles donnent une vue technique, pas comportementale.
Exemple : Le dashboard affiche « 200 requêtes/minute, latence 120ms, 0 % d’erreur ». Tout semble nominal. Pourtant, les agents consomment des volumes massifs de tokens LLM, générant des coûts imprévus. Certains entrent dans des boucles de raisonnement infinies, bloquant des workflows métier. Techniquement, pas d’erreur. Fonctionnellement, le système est cassé.
Il faut suivre : nombre d’agents actifs, actions par agent, chaînes de décisions moyenne, tokens LLM consommés, taux d’escalade humaine, temps de résolution d’un objectif. Ces métriques détectent les comportements anormaux avant qu’ils ne dégradent le service.
Les nouveaux patterns d’architecture
L’orchestration par agent superviseur
Un agent superviseur centralise les décisions de coordination. Il reçoit les intentions des autres agents, arbitre leur exécution, décide de l’ordre des actions et résout les conflits. Ce pattern convient aux environnements où la cohérence prime sur la réactivité (finance, workflows critiques). Le revers de cette approche : le superviseur devient un point de contention potentiel, et les agents perdent une partie de leur autonomie.
La liste blanche d’actions
Chaque agent dispose d’une liste explicite d’actions autorisées. Toute action hors liste est bloquée par défaut, même si l’agent a les permissions techniques. Cette approche inverse le modèle de sécurité traditionnel et prévient efficacement les actions imprévues. Recommandé pour les agents qui interagissent avec des données sensibles (finance, données personnelles, systèmes de production). La contrepartie : rigidité accrue et maintenance lourde de ces listes.
L’escalade automatique
Des règles déclenchent automatiquement une validation humaine pour certaines actions : montant financier, criticité de la donnée, niveau de confiance de l’agent, nombre d’étapes de raisonnement. Ce garde-fou n’empêche pas l’autonomie sur les tâches simples, mais ralentit les workflows nécessitant validation.
La traçabilité par graphe de décisions
Chaque décision d’agent est enregistrée sous forme de graphe : données consultées, raisonnements effectués, actions exécutées, ordre des étapes. Ce graphe permet de reconstituer le cheminement complet et devient indispensable dans les environnements régulés (santé, finance, secteur public) où la traçabilité des décisions automatisées est légale. Le coût : surcharge de stockage et complexité d’implémentation.
L’isolation par domaine
Chaque agent opère dans un domaine métier limité et ne peut pas sortir de son périmètre. Un agent de gestion des commandes qui doit réserver du stock sollicite un agent du domaine « Stock » via une API explicite, plutôt que d’accéder directement à la base. Cette séparation limite les impacts en cas de défaillance, mais restreint les cas d’usage possibles.
| Pattern | Principal avantage | Principal inconvénient | Cas d’usage type |
|---|---|---|---|
| Agent superviseur | Contrôle centralisé | Goulot d’étranglement | Finance, workflows critiques |
| Liste blanche d’actions | Sécurité renforcée | Rigidité, maintenance lourde | Données sensibles |
| Escalade automatique | Garde-fou sans blocage total | Ralentit certains workflows | Validation humaine sélective |
| Graphe de décisions | Auditabilité totale | Surcharge stockage | Environnements régulés |
| Isolation par domaine | Limitation des impacts | Restreint les cas d’usage | Architecture DDD |
Ce que les architectes doivent faire maintenant
Cartographier les risques. Identifier quels agents auront accès à quelles données et évaluer l’impact d’une action erronée. Cette cartographie permet de prioriser les efforts de sécurisation.
Définir les niveaux d’autonomie. Classer les agents en trois catégories : autonomie totale, autonomie supervisée, assistance pure. Cette classification doit être documentée et révisée régulièrement.
Implémenter les garde-fous techniques. Listes blanches d’actions, règles d’escalade, logs structurés. Ces garde-fous doivent être testés avant la production.
Tester les scénarios de défaillance. Simuler deux agents agissant simultanément, un agent prenant une mauvaise décision, l’annulation d’une séquence d’actions. Ces tests révèlent les failles avant la production.
Mettre en place l’observabilité. Dashboards spécifiques : agents actifs, actions par agent, chaînes de décisions, coûts LLM, taux d’escalade. Alertes sur comportements anormaux.
Conclusion
Les systèmes agentiques remettent en cause les fondations de l’architecture logicielle moderne. Les patterns éprouvés (microservices, event-driven, CQRS) restent valides, mais ne suffisent plus. Il faut les compléter avec de nouveaux mécanismes de coordination, de gouvernance et d’observabilité.
Les organisations qui intègrent ces patterns maintenant déploient des agents IA en production de manière contrôlée, sécurisée et auditable. Les autres subiront les incidents, les dérives de coûts et les incohérences fonctionnelles.
La question n’est plus de savoir si vous déploierez des agents IA dans votre SI. La question est : votre architecture est-elle prête ?