La plupart des entreprises qui abordent l’IA agentique commencent par la même question : quel modèle devrions-nous utiliser ? Ce n’est pas le bon point de départ. En pratique, la capacité du modèle détermine rarement le succès ou l’échec d’un programme. Ce qui le détermine, c’est tout ce qui se trouve en dessous — et la plupart des entreprises n’en ont pas encore pleinement pris conscience.
L’IA agentique dans les opérations TI n’est pas une simple mise à niveau par rapport à ce que la plupart des organisations ont déjà déployé. Les modèles prédictifs proposent des recommandations. L’IA générative aide les humains à rédiger et à synthétiser. Les systèmes agentiques font quelque chose de fondamentalement différent : ils agissent. Ils résolvent des incidents, reconfigurent l’infrastructure, déclenchent des processus en aval. Souvent sans attendre qu’un humain confirme quoi que ce soit. Ce passage de la recommandation à l’action change complètement l’équation de la préparation, et les risques qui n’étaient que des inconvénients lors des précédents déploiements d’IA — données incomplètes, garde-fous absents, flux de travaux déconnectés — deviennent de véritables passifs opérationnels.
Nous avons travaillé avec des entreprises qui ont investi massivement dans le choix du modèle tout en négligeant les fondations qui déterminent si cette capacité peut être déployée en toute sécurité. Le résultat : une IA agentique très performante dans un environnement de test, mais qui éprouve de grandes difficultés en production. Pour faire les choses correctement, il faut aborder la question de la préparation différemment dès le départ.
Fondation 1 : Télémétrie unifiée et qualité des données
S’il y a un élément qui distingue les entreprises réellement prêtes pour l’automatisation des opérations TI de celles qui ne le sont pas, c’est la volonté avec laquelle elles ont bâti l’infrastructure nécessaire pour collecter et normaliser les données opérationnelles. C’est le travail dont tout le reste dépend.
Les systèmes agentiques consomment la télémétrie pour comprendre l’état de l’environnement et décider quoi faire. Lorsque cette télémétrie est incohérente ou isolée par équipe, l’agent raisonne essentiellement sur une image déformée de la réalité. Il peut mal interpréter des signaux, agir sur des données obsolètes ou — plus dangereusement — manquer les premiers signes d’un échec en cascade, car les journaux pertinents se trouvent dans un système qu’il ne peut pas corréler. Un opérateur humain apporte un jugement contextuel à des données ambiguës. Un système agentique agit sur ce qu’il reçoit.
OpenTelemetry mérite d’être cité spécifiquement ici. En tant que norme ouverte et neutre pour collecter et exporter des métriques, événements, journaux et traces à travers des environnements hétérogènes, il normalise la télémétrie au niveau du pipeline sans exiger de remplacement complet des agents existants. La différence entre un système autonome raisonnant sur une télémétrie standardisée et corrélée et un système qui travaille avec une normalisation approximative de formats disparates n’est pas marginale. C’est la différence entre une base fiable pour l’action autonome et une base qui finira par produire un incident embarrassant.
Fondation 2 : Gouvernance et garde-fous
L’instinct dans de nombreuses organisations est de considérer la gouvernance comme une contrainte — quelque chose qui freine l’IA agentique. Nous remettons franchement en cause cette façon de voir : la gouvernance, c’est ce qui rend l’autonomie évolutive dès le départ.
Un système agentique sans garde-fous n’est pas plus performant. Il est plus dangereux. Dans les opérations TI, le rayon d’impact d’une action autonome incorrecte peut être important et se propager rapidement. Un retour en arrière mal configuré, un basculement erroné, une décision de capacité qui se répercute sur des services dépendants avant que quiconque ne remarque qu’il y a un problème. La question n’est jamais de savoir s’il faut contraindre les systèmes agentiques, mais comment les contraindre intelligemment, afin que l’autonomie s’accroisse au fur et à mesure que la confiance est gagnée, plutôt que comme un risque qui s’accumule discrètement en arrière-plan.
En pratique, cela signifie définir des limites claires concernant ce qu’un système est autorisé à faire sans examen humain. Les actions à faible risque et à haute fréquence — redémarrer un service, acquitter un motif d’alerte connu — peuvent être pleinement automatisées assez rapidement. Les actions à conséquence élevée impliquant des bases de données de production ou des systèmes ayant un impact sur les revenus devraient conserver une étape de validation humaine, du moins jusqu’à ce que le système ait démontré un jugement cohérent sur une période de temps significative. Pas une semaine. Pas un sprint. Juste assez de temps pour rencontrer des cas limites.
Les entreprises qui investissent tôt dans la mise en place de cette architecture de gouvernance voient leurs opérations agentiques évoluer beaucoup plus rapidement que celles qui traitent la gouvernance comme un enjeu de dernière étape. Bien définir la taxonomie des actions, rendre explicites les processus d’approbation, s’assurer qu’il existe un mécanisme crédible de retour en arrière avant qu’un problème ne survienne : ce travail de fond permet à l’autonomie de croître sans perte de confiance organisationnelle. La confiance, une fois brisée par une action autonome à grande échelle qui dérape, met longtemps à se rétablir. Nous avons vu des programmes interrompus pendant des mois après un incident qui, avec de meilleurs garde-fous, aurait été détecté avant de se propager.
Fondation 3 : Intégration aux flux de travail
Un client avec lequel nous avons travaillé l’an dernier avait pratiquement tout bien fait. Pipeline de télémétrie propre, cadre de gouvernance approuvé par leur CISO, un modèle performant à travers leurs scénarios d’incidents. Trois mois après le début de la production, le programme a heurté un plafond qu’aucun n’avait anticipé : l’agent pouvait diagnostiquer et corriger de manière compétente dans son propre domaine opérationnel, mais une partie importante des incidents nécessitait une action au-delà des frontières d’équipe. Déclencher un retour en arrière de déploiement nécessitait d’accéder au pipeline CI/CD appartenant à une autre équipe d’ingénierie, avec ses propres contrôles d’approbation. Faire évoluer l’infrastructure passait par un flux de capacité pensé pour des planifications trimestrielles, pas pour des décisions autonomes en temps réel. L’agent trouvait la bonne solution, puis s’arrêtait à une frontière sans pouvoir aller plus loin.
C’est là le problème d’intégration aux flux de travail sous sa forme concrète. Une IA agentique capable qui ne peut pas agir dans les processus opérationnels existants est, en pratique, un moteur de recommandations coûteux. Toutes les autres fondations deviennent inutiles si la prise de décision de l’agent s’arrête systématiquement à une frontière organisationnelle : ces points de friction s’accumulent plus vite que la plupart des équipes ne l’anticipent, et le programme perd discrètement son mandat.
L’écart entre la démo et la production est particulièrement marqué à ce niveau, car les démos sont conçues dans des environnements contrôlés avec des API propres et des processus simplifiés. Les environnements de production ont des flux créés pour des acteurs humains naviguant dans les réalités organisationnelles : étapes d’approbation, frontières interéquipes, cadences de planification sans rapport avec la vitesse d’un système autonome. S’intégrer à cette réalité exige des travaux de connectivité API, un véritable redesign des processus, et une conversation interne honnête pour déterminer si les flux actuels doivent évoluer pour accueillir un nouvel acteur opérationnel.
La plupart des entreprises n’ont pas encore eu cette discussion. Celles qui l’amorcent avant d’y être forcées sont nettement mieux positionnées.
Fondation 4 : Sélection du modèle
Ce n’est pas le manque de conseils qui fait défaut à ce sujet. Les banques de tests, panels comparatifs et présentations d’analystes traitent la capacité du modèle comme la variable principale du succès de l’IA. C’est important. Mais cet aspect compte bien moins que ne le pensent la plupart des entreprises, et ce n’est presque jamais sur ce point qu’il faudrait d’abord investir de l’énergie.
Dans les opérations TI, les tâches réalisées par les systèmes agentiques sont suffisamment bien définies pour qu’on puisse s’appuyer sur plusieurs modèles capables de les traiter adéquatement. Le différenciateur réside rarement dans la capacité du modèle à raisonner en isolation dans un test comparatif. C’est plutôt le fait que le modèle reçoive une télémétrie de qualité, fonctionne dans le cadre de garde-fous adéquats et puisse agir dans des flux de travail intégrés. Un système agentique bien gouverné et bien intégré, fondé sur un modèle compétent mais sans éclat, surpassera systématiquement un modèle de pointe reposant sur des données fragmentées, sans garde-fous et avec une faible connectivité des flux de travail. Nous l’avons constaté en direct — ce n’est même pas comparable.
La sélection du modèle est aussi la décision la plus facilement réversible du lot. Remplacer un modèle est relativement simple une fois que l’infrastructure environnante est solide. Rebâtir une base de données ou refondre la gouvernance ne l’est pas. Les entreprises qui commencent par la sélection du modèle se retrouvent souvent à revisiter les questions les plus complexes par la suite — en général, après un incident qui rend le post-mortem inconfortable.
La perspective de préparation qui change tout
La conversation la plus difficile que nous avons généralement avec nos clients est aussi la première : leur dire que le modèle qu’ils ont évalué pendant trois mois est, en réalité, le moindre de leurs problèmes. Que la couche d’observabilité qu’ils considéraient comme un outil de rapport est en fait une infrastructure essentielle. Que leur processus de gestion du changement, tel que conçu, va discrètement étouffer toute autonomie qu’ils arriveraient à déployer.
Les opérations TI autonomes ne constituent pas un projet d’IA avec quelques considérations d’infrastructure. Il s’agit d’une transformation opérationnelle, et la capacité d’IA n’est aussi bonne que ce sur quoi elle repose : bases de données, gouvernance, intégration aux flux de travail. La plupart des entreprises n’ont pas encore mis en place ces éléments de façon complète. Certaines le savent et y travaillent. D’autres l’apprennent à leurs dépens, souvent entre le pilote et le premier véritable incident en production.
Les organisations qui réussissent ne sont pas forcément celles qui ont le plus gros budget IA ou les modèles les plus avancés. Ce sont celles qui ont eu l’honnêteté, dès le départ, de reconnaître où étaient les lacunes — et qui y ont consacré leur énergie en priorité.
