Entre IA First et shadow IA : l’écart réel de maturité IA de votre organisation !
Entre IA First et shadow IA : l'écart réel de maturité IA de votre organisation !
L’intelligence artificielle s’impose progressivement comme un élément incontournable des stratégies de transformation des services de support aux utilisateurs. Dans de nombreuses organisations, l’approche « IA First » consiste désormais à privilégier l’automatisation et les interactions assistées par l’IA avant toute intervention humaine. Cette orientation répond à des objectifs de performance, de disponibilité et de maîtrise des coûts.
Parallèlement, un phénomène plus discret mais tout aussi significatif se développe : la « Shadow IA ». À l’image du Shadow IT, elle désigne l’utilisation, souvent non encadrée, d’outils d’intelligence artificielle par les collaborateurs pour répondre à leurs besoins quotidiens.Une étude Microsoft / YouGov de Février 2026 estime que 61% des utilisateurs d’IA en entreprise le font à travers leurs comptes personnels.
Entre promesse d’amélioration de la satisfaction utilisateur et nouveaux risques organisationnels, l’IA ouvre un champ de réflexion majeur pour les entreprises.
L’IA au service d’une meilleure satisfaction utilisateur
Les attentes des utilisateurs évoluent rapidement. Ils recherchent des réponses immédiates, personnalisées et accessibles à tout moment.
L’IA peut répondre à plusieurs de ces exigences dans la mesure où son intégration est faite sur des bases et référentiels ordonnés, adaptés et gouvernés.
Une disponibilité permanente
Les assistants conversationnels et les agents virtuels offrent un accès aux services 24 heures sur 24 et 7 jours sur 7. Les utilisateurs obtiennent des réponses sans dépendre des horaires de disponibilité des équipes de support.
Cette réactivité contribue fortement à une meilleure qualité perçue du service.
Une résolution plus rapide des demandes
Grâce à l’automatisation et à l’exploitation des bases de connaissances, l’IA permet de traiter rapidement les demandes : elle peut interpréter les termes non techniques des utilisateurs pour les traduire en besoins dont la solution se trouve dans le catalogue de service.
Les utilisateurs bénéficient ainsi de délais de traitement réduits et d’une expérience plus fluide.
Une personnalisation accrue
L’analyse des données et des historiques d’interaction permet d’adapter les réponses aux besoins spécifiques de chaque utilisateur.
Cette personnalisation renforce le sentiment d’accompagnement et améliore la qualité perçue du service.
Un support augmenté pour les agents
L’IA ne profite pas uniquement aux utilisateurs finaux. Elle assiste également les équipes de support en proposant des diagnostics, des recommandations ou des réponses pré-rédigées.
Les agents gagnent en efficacité et peuvent consacrer davantage de temps à l’accompagnement des utilisateurs, et d’énergie au traitement des situations complexes.
Les limites d’une approche « IA First »
Malgré ses avantages indéniables, une stratégie consistant à placer systématiquement l’IA en première ligne présente plusieurs risques.
La déshumanisation de la relation
Certaines situations nécessitent de l’empathie, du discernement ou une compréhension fine du contexte.
Lorsque l’utilisateur se trouve confronté à une succession de réponses automatisées inadaptées, la frustration augmente rapidement.
Une satisfaction initialement recherchée peut alors se transformer en insatisfaction durable.
Il est donc impératif de donner aux utilisateurs une “porte de sortie” ou que l’IA soit en mesure d’identifier rapidement les situations qui nécessitent une touche humaine.
La perte de confiance
Les systèmes d’IA générative peuvent produire des erreurs, des approximations ou des réponses incohérentes.
Même lorsque leur taux de réussite est élevé, quelques erreurs visibles suffisent parfois à dégrader la confiance des utilisateurs.
La fiabilité perçue devient alors un facteur critique d’acceptation.
Dans une lignée similaire, les réponses par IA sont, de par la nature même de ces outils, génériques. Les cas sortant de la “norme” d’appréciation du modèle doivent pouvoir être pris en charge par des humains plus à même d’apprécier les nuances de ladite situation. Sans cela, les utilisateurs risquent de retomber dans l’appréciation du service IT qui “ne comprend rien à leur besoin”.
La montée de la Shadow IA
Face à la disponibilité croissante des outils d’IA générative, de nombreux collaborateurs développent leurs propres usages sans attendre les initiatives officielles de l’entreprise.
Cette pratique est souvent motivée par la recherche d’efficacité :
Rédaction de documents.
Synthèse d’informations.
Recherche de solutions techniques.
Assistance à la prise de décision.
Création de contenus.
La Shadow IA révèle généralement un besoin réel auquel les outils institutionnels ne répondent pas suffisamment rapidement.
Une opportunité d’innovation
La Shadow IA ne doit pas être perçue uniquement comme une menace.
Elle constitue également un indicateur précieux des attentes des utilisateurs et de leur capacité à s’approprier les nouvelles technologies.
Les organisations peuvent y voir un laboratoire d’innovation permettant d’identifier les usages les plus créateurs de valeur.
Des risques importants pour l’organisation
Cependant, l’usage non encadré de solutions d’IA soulève plusieurs préoccupations.
Risques liés à la sécurité des données
Des informations sensibles peuvent être partagées involontairement avec des services externes.
Les enjeux de confidentialité, de propriété intellectuelle et de conformité réglementaire deviennent alors majeurs.
Risques liés à la qualité de l’information
Les réponses produites par certaines IA peuvent contenir des erreurs ou des biais.
Sans validation humaine, ces contenus peuvent alimenter des décisions inadaptées ou diffuser des informations erronées.
Risques de fragmentation des pratiques
Lorsque chaque collaborateur utilise ses propres outils, les méthodes de travail deviennent hétérogènes et plus difficiles à gouverner.
L’organisation perd alors en cohérence et en maîtrise de ses processus.
Trouver un équilibre : vers une stratégie « Human Centric AI »
La véritable question n’est pas de choisir entre l’humain et l’intelligence artificielle.
Les organisations les plus performantes s’orientent progressivement vers des modèles hybrides dans lesquels :
L’IA traite les demandes simples et répétitives.
Les agents humains interviennent sur les situations complexes.
Les utilisateurs conservent la possibilité de choisir le canal le plus adapté à leur besoin.
Les usages de l’IA sont encadrés par une gouvernance claire.
Cette approche permet de concilier performance opérationnelle, maîtrise des risques et satisfaction des utilisateurs.
Cette organisation demande néanmoins une approche extrêmement cadrée et vigilante. Par exemple, l’AI act, dans son article 26, pose clairement les obligations des organisation déployant des systèmes d’IA à haut risque ; ie dans certains domaines touchant à l’appréciation des personnes ou de leur performance (e.g éducation et formation professionnelle, emploi et gestion de personnel, etc)
Dépendance et enjeux économique
Les outils IA sont, pour le moment, assez différents les uns des autres pour que leurs spécificités puissent avoir un impact différent en fonction des contextes. Il est néanmoins important de trouver des cas d’usage précis et d’avoir en place une gouvernance qui permettra de mesurer l’apport de cette intégration d’IA. Aujourd’hui de nombreuses entreprises ont une solution IA en place dont la consommation n’est pas suivie ce qui peut faire exploser la facture. De même, en plus des formations aux enjeux de données d’entreprise, avoir des interlocuteurs assez éclairés sur le sujet pour aider les utilisateurs à “traduire” leur travail effectué avec “shadow AI” dans les outils corporate semble primordial pour le limiter.
L’intelligence artificielle représente une formidable opportunité pour améliorer l’expérience et la satisfaction des utilisateurs. Elle apporte rapidité, disponibilité et personnalisation tout en augmentant les capacités des équipes de support.
Cependant, une stratégie « IA First » menée sans discernement peut générer de nouvelles frustrations, tandis que le développement de la Shadow IA révèle autant un potentiel d’innovation qu’un besoin de gouvernance.
L’enjeu pour les organisations n’est donc pas d’automatiser à tout prix, mais de construire un équilibre durable entre intelligence artificielle et intelligence humaine. La satisfaction des utilisateurs de demain dépendra moins du niveau d’automatisation que de la capacité à proposer une expérience de service efficace, fiable et adaptée aux attentes réelles des utilisateurs.
Le sujet est particulièrement pertinent en 2026 car il permet d’aborder simultanément trois tendances majeures : l’« IA First », la « Shadow IA » et l’expérience utilisateur, qui sont aujourd’hui au cœur des programmes de transformation des services support et des centres de services numériques.
Ces tendances doivent pouvoir être contrôlées à travers une adaptation des organisations et des responsabilités permettant une utilisation efficiente en accord avec le contexte réglementaire (CNIL, AI Act).
L’AIOps va-t-il réduire le coût de votre production informatique ?
L'AIOps va-t-il réduire le coût de votre production informatique ?
Réponse : non sans changement de modèle opérationnel. Quatre leviers, deux indicateurs, une séquence.
En 2025, Gartner a renommé sa catégorie de marché « AIOps Platforms ». Le motif est explicite : le terme avait été repris par les éditeurs de tous les segments de l’IT Operations sans définition claire ni consensus, ce qui a produit chez les responsables Infrastructure & Operations une déception à la hauteur d’attentes non tenues. La catégorie s’appelle désormais Event Intelligence Solutions. Son périmètre est resserré : appliquer l’IA et l’analytique à des événements multi-domaines issus des outils de supervision et d’observabilité, pour augmenter, accélérer et automatiser la réponse.
Ce renommage ne disqualifie pas la technologie. Les capacités de corrélation fonctionnent, et nous les détaillons plus bas. Il constate que des organisations ont acheté une promesse d’économies et obtenu autre chose.
Notre diagnostic : la cause n’est pas l’outil, c’est le modèle opérationnel dans lequel il est déployé. Ce modèle a été dimensionné, financé et contractualisé pour absorber un volume élevé d’événements. Supprimer le bruit sans modifier le modèle ne supprime pas le coût du modèle. Le résultat est une production plus calme, au même prix, augmenté d’une licence.
Le point déterminant est donc moins la réduction théorique de charge que la capacité à transformer cette réduction en coût réellement évité.
La suite est organisée ainsi : la structure de coût, les capacités réellement disponibles, les quatre leviers de modèle opérationnel, les coûts ajoutés, les deux indicateurs de décision et la séquence d’exécution.
Structure de coût : pourquoi la dépense ne baisse pas d’elle-même
À l’échelle d’une DSI, les ordres de grandeur relevés par Forrester donnent une première lecture de la structure de dépense : masse salariale 35 %, prestations externes 25 %, logiciel 23 %. Ces chiffres montrent le poids considérable des ressources internes et externes dans l’économie d’une DSI.
Mais cette vision consolidée ne suffit pas pour évaluer un projet AIOps. Le bon niveau d’analyse est le périmètre de production réellement concerné par l’automatisation.
La première étape consiste donc à établir une baseline du coût récurrent de production comprenant notamment :
exploitation et supervision
observabilité et gestion des événements
support technique
maintien en conditions opérationnelles et de sécurité des infrastructures et plateformes
astreintes
infogérance associée
outillage technique du run
Les projets de transformation et les licences applicatives métier sont exclus de cette baseline.
Poste
Effet potentiel d’un déploiement AIOps
Équipes internes
Gain partiel : tri des alertes, corrélation, qualification, routage et progressivement remédiation. Effet plus limité sur les changements, la capacité, les obsolescences ou certaines activités de support.
Prestations externes
Gain dépendant directement de l’élasticité du modèle contractuel et de la capacité à convertir la baisse d’activité en baisse de facture.
Logiciel
Augmentation directe et récurrente liée aux nouvelles capacités acquises.
Infrastructure / télémétrie
Augmentation possible liée au volume de données collectées, ingérées, analysées et conservées.
Les coûts de production ne se contractent pas automatiquement lorsque la charge diminue. Ils peuvent rester immobilisés par plusieurs structures :
un contrat d’infogérance comportant un socle forfaitaire, des bandes de volumétrie, des minimums de staffing ou des engagements de capacité
une organisation de support dimensionnée sur des volumes historiques
des plages d’astreinte calibrées sur un niveau d’activité antérieur
des outils devenus partiellement redondants mais qui continuent d’être exploités et licenciés
Ces structures ne réagissent pas spontanément à une baisse de volume. Elles réagissent à une décision de management. Un outil ne prend pas cette décision.
Capacités réellement disponibles
Capacité
Maturité
Caractérisation et ordres de grandeur
Réduction du bruit événementiel
Mature
Jusqu’à plus de 95 % d’événements en moins nécessitant une intervention humaine dans certains cas extrêmes rapportés par Gartner.
Corrélation et agrégation de contexte
Mature
Regroupement des symptômes d’une même défaillance ; suppression des tempêtes de notifications.
Accélération du triage
Mature
Gain réel, très dépendant de la qualité du référentiel de services et de la connaissance des dépendances.
Remédiation autonome
Émergente
Gartner projette 70 % d’entreprises déployant des agents pour opérer leur infrastructure IT d’ici 2029, contre moins de 5 % en 2025.
Gartner relève par ailleurs qu’il n’est pas rare qu’une grande entreprise exploite un portefeuille de cinq à cinquante outils de supervision, chacun produisant des signaux à corréler et à traiter.
Ces capacités reposent sur la qualité des données : événements normalisés, référentiel de services à jour et dépendances connues. Sans ce socle, la corrélation reste fragile et la remédiation difficile à sécuriser. La remise à niveau de la télémétrie et des référentiels doit donc être intégrée au coût et au calendrier du programme dès le diagnostic.
Un résultat contre-intuitif mérite d’être noté : le bruit n’est pas seulement coûteux, il est dangereux. Lorsque les équipes sont exposées à un volume excessif d’alertes, la fatigue opérationnelle augmente le risque qu’un signal pertinent soit ignoré ou qu’un incident ne soit identifié que tardivement.
Le bénéfice le plus rapide de l’AIOps est la panne évitée, avant l’heure économisée.
Ces gains opérationnels sont réels. Ils ne se retrouvent pas automatiquement dans le budget, et cela pour trois raisons : le contrat continue de facturer une capacité devenue surdimensionnée ; la structure d’équipe continue d’exister pour un volume de travail réduit ; le temps libéré est réabsorbé par l’activité courante.
Trois canaux, quatre leviers pour les fermer.
Levier 1 — Le contrat d’infogérance
C’est le levier de plus fort impact, et souvent le moins traité.
Une part significative de l’exploitation peut être infogérée selon des modèles combinant forfait, unités d’œuvre, équipements supervisés, tickets, capacités ou ETP staffés.
La réduction du volume opérationnel ne se transforme en économie que dans la mesure où le modèle contractuel rend effectivement les coûts variables.
Un contrat comportant un socle forfaitaire, des minimums de staffing, des bandes de volumétrie ou des engagements de capacité peut absorber une grande partie du gain de productivité sans réduire la facture.
Situation contractuelle
Résultat
Contrat peu élastique au volume
La charge opérationnelle diminue mais une partie importante du coût reste inchangée.
Contrat réellement variable
Une partie du gain peut être automatiquement restituée au client avec la diminution des unités effectivement consommées.
Automatisation déployée par le prestataire à prix constant
Le gain de productivité est principalement capté par le prestataire.
Contrat révisé en cohérence avec la transformation
Le gain est partagé selon une règle définie et mesurable.
Cinq points sont à instruire avant de choisir un outil :
Clause de partage des gains d’automatisation : règle de répartition de l’économie réalisée sur les volumes automatisés et mécanisme de mesure contradictoire
Bascule progressive des unités d’œuvre vers des engagements de résultat lorsque cela est pertinent : une stratégie d’automatisation doit être accompagnée d’un modèle économique compatible avec la réduction des volumes
Révision des seuils de staffing et des plages d’astreinte, indexée sur les volumes et niveaux de service réellement constatés
Qualification réglementaire et clarification des responsabilités entre les différents acteurs lorsque les usages d’IA concernés entrent dans le champ applicable de l’AI Act
Réversibilité des règles de corrélation, runbooks, politiques et automates produits par le prestataire : ce sont des actifs dont la restitution doit être prévue dès le début de la relation
Déployer l’AIOps sans rouvrir le modèle contractuel revient à financer une amélioration de productivité dont un autre captera la valeur.
La pyramide de support répond à une condition économique précise : un volume élevé d’événements majoritairement simples, qu’il est rentable de faire traiter par des profils moins coûteux avant escalade.
Levier 2 — La pyramide N1 / N2 / N3
La logique est saine tant que ce volume existe.
C’est précisément sur ce volume que la combinaison corrélation + enrichissement + automatisation produit ses premiers effets. Une partie des événements est supprimée comme bruit, une autre est regroupée et une partie croissante des actions répétitives peut être automatisée.
Ce qui subsiste tend donc à contenir proportionnellement davantage d’incidents complexes, transverses ou nécessitant une expertise spécifique.
Si le volume d’activité simple diminue structurellement, le modèle de dimensionnement doit évoluer avec lui. Maintenir une pyramide conçue pour absorber un flux qui s’est fortement réduit revient à conserver une capacité de triage et de routage devenue partiellement redondante.
Le travail peut alors être payé deux fois : une première fois par l’automatisation, une seconde par une organisation restée dimensionnée sur l’ancien modèle.
Le modèle cible évolue progressivement vers :
des équipes davantage alignées sur les services que sur les seules technologies
une résolution en essaim permettant de mobiliser directement les compétences pertinentes sans multiplier les chaînes d’escalade
une automatisation croissante des opérations répétitives
une astreinte requalifiée autour de la supervision des automatismes et du traitement de l’exception
Trois conséquences sont à assumer : un plan de compétences, parce que superviser des automatismes ou des agents et écrire des politiques d’automatisation n’est pas le métier historique d’un opérateur N1 ; une trajectoire sociale lorsque les effectifs concernés sont internes ; une renégociation du périmètre externalisé, qui renvoie au levier 1.
Levier 3 — La matrice de délégation d’action
Il faut ici distinguer plusieurs niveaux de maturité.
Niveau
Capacité
Prérequis de maîtrise
1. Event Intelligence
Collecter, corréler, enrichir et prioriser les événements
Référentiel de services et dépendances à jour
2. Automatisation déterministe
Exécuter des runbooks sur des scénarios connus
Runbooks documentés, versionnés et testés
3. Remédiation automatisée
Déclencher l’action corrective sans intervention humaine
Matrice de délégation, rollback testé, journalisation
4. Approches agentiques
Diagnostiquer, décider et agir de façon autonome
Bornage des privilèges, kill switch, double validation sur les actions sensibles
Plus le dispositif se déplace de la recommandation vers l’action, plus la question de gouvernance devient centrale.
Un agent qui diagnostique produit une recommandation. Un agent qui agit produit un risque.
Entre les deux se situe une décision de gouvernance : qui autorise quoi, sur quel périmètre, avec quelle réversibilité, et qui répond en cas d’erreur ?
Le livrable à produire avant toute automatisation significative de remédiation est une matrice de délégation d’action.
Classe de service
Action autonome
Action sous validation
Action interdite
Non critique
Redémarrage de service, purge de cache, extension de volume, scale-out
Rollback de version
Modification sensible de configuration réseau
Critique
Scale-out dans une enveloppe bornée, bascule sur nœud sain
Redémarrage de service, rollback
Actions non maîtrisées sur les données
Vital
Aucune ou actions strictement bornées et pré-approuvées
Actions critiques sous double validation
Actions irréversibles ou non testées
Chaque ligne porte un propriétaire nommé, un mécanisme de retour arrière et une trace d’audit.
Le document est court, de l’ordre de quelques pages, mais il est bloquant : en son absence, les équipes plafonnent volontairement l’automatisation par prudence et une partie des capacités de remédiation achetées n’est jamais activée.
Automatiser crée également un nouveau risque opérationnel
Une erreur humaine affecte généralement le périmètre sur lequel intervient l’opérateur. Une mauvaise règle d’automatisation ou un agent disposant de privilèges élevés peut reproduire une erreur simultanément sur un grand nombre de composants.
L’automatisation augmente donc le blast radius — le périmètre affecté par une action — d’une mauvaise décision.
Le niveau d’autonomie doit progresser avec la capacité de contrôle :
périmètres d’action bornés
principe du moindre privilège
rollback automatique et régulièrement testé
journalisation exhaustive des décisions et actions
limites de consommation et de fréquence
mécanisme de suspension ou kill switch
validation humaine ou double validation pour les actions les plus sensibles
L’objectif n’est pas de limiter l’automatisation. Il est de rendre possible son passage à l’échelle sans augmenter proportionnellement le risque opérationnel.
Cette matrice a donc un triple usage : débloquer l’automatisation là où le risque est faible ; encadrer l’augmentation progressive de l’autonomie ; fournir une preuve de maîtrise utile aux exigences de contrôle, de sécurité et de résilience opérationnelle.
Levier 4 — Le système de mesure
Piloter un programme AIOps uniquement au MTTR est une erreur de conception.
Le MTTR reste utile pour mesurer la rapidité de rétablissement du service. Mais il ne suffit pas à mesurer la valeur opérationnelle et encore moins économique d’un programme AIOps, pour trois raisons :
il récompense la rapidité de résolution d’incidents qui, idéalement, n’auraient pas dû se produire
il peut être influencé par les mécanismes de corrélation et de regroupement des événements, rendant certaines comparaisons avant/après trompeuses
il ne contient aucune information de coût
Indicateur
Définition
Ce qu’il pilote
TEA — taux d’événements actionnables
Indicateur de diagnostic de la part des événements actionnables dans la chaîne de supervision
Le gisement de bruit et l’applicabilité du cas d’usage principal
Taux de résolution sans intervention humaine
Incidents clos sans action humaine / incidents totaux, par classe de criticité
La progression effective de l’automatisation
Part du run consommée par le non planifié
Charge d’exploitation absorbée par l’imprévu / charge d’exploitation totale
La capacité potentiellement restituable à la transformation
Sans mesure initiale, le gain ne sera pas démontrable. Un gain non démontré devient difficilement un gain budgétaire.
Coûts ajoutés par le dispositif
Poste
Nature
Télémétrie
Coût récurrent lié à la collecte, l’ingestion, l’analyse, le stockage et la rétention des logs, métriques, traces et événements
Qualité de donnée et intégration
Référentiel de services, dépendances applicatives, normalisation et nomenclature cohérente entre les différents outils
Tuning des modèles de corrélation
Charge continue liée à l’évolution du SI et des patterns opérationnels
Dépendance à la feuille de route éditeur
Risque technologique et économique
À dire d’expert, sur les environnements cloud-native fortement instrumentés, le coût complet de collecte, ingestion, stockage et rétention de la télémétrie peut représenter plusieurs points du coût d’infrastructure et atteindre des niveaux à deux chiffres dans certains environnements intensifs.
Les repères de marché convergents situent cette dépense autour de 7 à 12 % du coût d’infrastructure cloud en médiane, avec 8 à 15 % sur les stacks Kubernetes intensifs et jusqu’à 15 à 25 % sur les architectures distribuées multi-régions.
Ces ordres de grandeur ne constituent pas un benchmark universel. Ils dépendent fortement du volume de logs et de traces, de la cardinalité, des politiques de rétention, de la distribution géographique et de l’architecture retenue.
L’enquête Elastic 2026 sur l’observabilité indique que 96 % des organisations interrogées pilotent activement ces coûts et que 70 % cherchent à optimiser l’existant plutôt qu’à simplement réduire la donnée collectée.
Le poste télémétrie se pilote en amont, pas en aval : filtrage, échantillonnage, agrégation et hiérarchisation des rétentions avant ingestion.
C’est une décision d’architecture et de gouvernance, à l’intersection de l’AIOps et du FinOps — deux périmètres encore souvent portés par des équipes distinctes.
Deux indicateurs de décision
Le choix d’un outil est prématuré tant que ces deux grandeurs ne sont pas établies.
Nous utilisons le TEA comme repère de diagnostic CTO Advisory pour apprécier le gisement de bruit avant d’engager un programme.
Son interprétation doit tenir compte de la criticité, du type d’infrastructure et de la chaîne de supervision existante. Il éclaire le potentiel de corrélation et d’automatisation ; il ne suffit pas, à lui seul, à conclure à la rentabilité du programme.
La question qui tranche n’est pas seulement la valeur du ratio, mais celle-ci : ce point mort est-il atteignable sans les quatre leviers ?
Dans la grande majorité des situations que nous rencontrons, notre réponse est non.
Cela ne disqualifie pas le projet. Cela le requalifie : il ne s’agit pas d’un achat d’outil mais d’une transformation du modèle opérationnel dont l’outil est un composant. Le sponsor, le mandat et le calendrier ne sont pas les mêmes.
Notre conviction de cabinet
Notre retour d’expérience nous conduit à considérer que, sans transformation du modèle opérationnel, le gain net sur le run à trois ans peut rester proche de zéro.
Avec les quatre leviers menés jusqu’au bout, une réduction de 15 à 25 % du coût récurrent du périmètre de production concerné à trois ans nous paraît atteignable.
La borne haute suppose que les gains techniques soient effectivement convertis en gains économiques :
redimensionnement des prestations ;
évolution du dimensionnement des équipes ;
automatisation effective des opérations répétitives ;
adaptation des astreintes ;
décommissionnement des outils devenus redondants ;
réduction réelle des capacités devenues inutiles.
Ce 15 à 25 % est une conviction issue de notre retour d’expérience et non un benchmark universel de marché.
Le gain est durable parce qu’il porte sur la structure du modèle de production et non uniquement sur l’outillage.
Précision de périmètre : ce gain porte sur la baseline du coût récurrent de production définie précédemment — exploitation, supervision et observabilité, support technique, MCO/MCS infrastructures et plateformes, astreintes, infogérance et outillage technique du run — hors projets de transformation et licences applicatives métier.
Ainsi, pour 100 M€ de coût récurrent de production concerné, la cible économique à trois ans se situe dans notre modèle entre 15 et 25 M€ de réduction annuelle de run, sous réserve que l’ensemble des leviers soit effectivement activé.
C’est cette baseline — et non le budget global de la DSI — qui doit servir au business case.
Séquence d’exécution
La séquence la plus fréquemment observée commence par l’outil : appel d’offres, POC, déploiement, puis constat après plusieurs mois que le budget n’a pas significativement bougé et tentative de rattrapage contractuel et organisationnel en position de faiblesse.
L’outil est installé. Le prestataire le sait. La marge de négociation a diminué.
La séquence recommandée inverse les deux premières phases.
Phase
Durée
Livrables
Décision produite
1. Diagnostic
6 à 8 semaines
Baseline économique du run ; TEA mesuré ; cartographie de la chaîne événementielle ; inventaire des outils de supervision/observabilité ; audit du modèle contractuel ; calcul du point mort
Engager ou ne pas engager
2. Cible opérationnelle — avant signature
Un trimestre
Plan de décommissionnement daté et nominatif ; évolution contractuelle et mécanisme de partage des gains ; matrice de délégation d’action ; trajectoire d’organisation et de compétences ; modèle de maîtrise du risque d’automatisation ; instrumentation des indicateurs
Cahier des charges et modèle cible
3. Déploiement et industrialisation
Selon périmètre
Mise en œuvre ; augmentation progressive de l’autonomie ; décommissionnement effectif ; redimensionnement ou réallocation des capacités
Réalisation du gain
La phase 2 est celle qui est le plus souvent omise. C’est pourtant elle qui détermine le résultat économique.
Synthèse pour le comité de direction
L’AIOps réduit le risque avant de réduire le coût. Le bénéfice le plus rapide peut être la panne évitée. C’est un argument recevable, à condition de l’assumer plutôt que d’annoncer une économie qui n’arrivera pas automatiquement.
L’économie provient de la transformation du modèle de production : contrat, organisation, automatisation et décommissionnement. L’algorithme rend cette transformation possible ; il ne matérialise pas seul l’économie.
L’automatisation crée également un risque. Plus la capacité d’action augmente, plus le périmètre, les privilèges, le rollback, l’audit et le blast radius doivent être maîtrisés.
Le point d’entrée est la mesure du TEA et de la baseline du run — les deux prérequis sont économiques et contractuels avant d’être technologiques. Une organisation qui ne connaît ni son niveau de bruit ni le coût du périmètre qu’elle veut automatiser ne dispose pas encore des éléments permettant de construire son business case.
Pour évaluer le potentiel de l’AIOps dans votre contexte, Rhapsodies Conseil propose un échange de cadrage sur votre modèle de production, vos contrats et les conditions de réalisation des gains.
Sources principales
Gartner, Market Guide for Event Intelligence Solutions, 2025 — évolution de la catégorie AIOps, périmètre de l’Event Intelligence et capacités de corrélation.
Gartner, Predicts 2026: AI Agents Will Transform IT Infrastructure and Operations, C. Haight et al., 4 décembre 2025.
Forrester France — structure du budget DSI : masse salariale, prestations externes et logiciel, citée par CIO Online, septembre 2025.
Elastic, 2026 Observability Survey — pilotage et optimisation des coûts d’observabilité.
FinOps Foundation, CNCF et travaux de marché relatifs à la maîtrise des coûts de télémétrie et d’observabilité cloud-native.
Règlement européen sur l’intelligence artificielle — qualification des systèmes et responsabilités applicables selon les usages.
Conduite du changement et changement d’infogéreur : l’angle mort du pilotage IT
Conduite du changement et changement d’infogéreur : l'angle mort du pilotage IT
Quand une DSI change de prestataire d’infogérance, le l’équipe projet se focalise sur les points essentiels de la contractualisation : les clauses contractuelles, la description des services et les engagements associés, le plan de transition, les conditions financières, Ces éléments masquent une question tout aussi structurante, rarement traitée avec la même application et dans le bon timing qu’est-ce qui change, concrètement, dans la façon dont la DSI et ses clients internes travaillent au quotidien ?
Le contrat bascule d’un prestataire à l’autre. Comment l’organisation doit apprendre à fonctionner autrement ?
Sans cet apprentissage, la transition prévu sur le papier s’essouffle très rapidement sur le terrain.
Un changement de prestataire n’est pas qu’un changement de fournisseur
On instruit souvent ces transitions comme un projet opérationnel: on requalifie un périmètre de services, on négocie des engagements, on organise une bascule technique. Un diagnostic complémentaire permet de poser d’autres questions, tout aussi structurantes :
Comment pilote-t-on le passage d’un prestataire à l’autre pendant la période de transition ?
Quelles interactions entre la DSI et son prestataire changent réellement, au-delà de l’organigramme du contrat ?
Et surtout, qu’est-ce qui change du côté du client lui-même : son organisation interne, les participants à ses instances de gouvernance ?
Le vrai changement se joue côté client, pas côté prestataire
C’est le point que l’on sous-estime le plus souvent : l’essentiel de l’effort d’adoption ne porte pas sur les équipes du nouveau prestataire, mais sur la DSI et ses clients internes (managers et utilisateurs) qui doivent changer leurs réflexes. «avant, nous faisions comme cela ; maintenant, nous devons faire comme ci». Sans accompagnement dédié, ces réflexes ne changent pas d’eux-mêmes : la bascule technique et contractuelle peut être parfaitement exécutée et ne produire, sur le terrain, qu’un changement de logo sur les tickets.
Rendre la bascule tangible pour ceux qui la vivent
En pratique, cela veut dire traiter la Conduite du changement comme un volet du projet de transition, pas comme une option ajoutée après la signature du contrat : un diagnostic flash mené dès le cadrage pour objectiver les écarts d’usages, un plan d’adoption qui distingue les cibles techniques de la DSI des cibles métier, des indicateurs d’adoption suivis dans la durée au même titre que les indicateurs de service, et des formats de communication qui rendent la transition concrète ; jusqu’à des formats vidéo qui font vivre à chacun une journée dans la peau d’un utilisateur touché par le changement.
Un sujet CIO Office à part entière
Piloter cette dimension ne relève pas d’un service annexe qu’on ajoute une fois le contrat signé. C’est un sujet CIO Office à part entière, au même titre que la gouvernance de la relation prestataire ou le pilotage de la performance des services. Et c’est aussi un sujet qui se joue à la croisée de deux expertises complémentaires : l’expertise Conduite du changement, du côté de notre practice CIO Office, qui structure l’accompagnement humain et organisationnel de la transition ; et notre practice Digital Collaborateur, qui pilote au quotidien les transitions d’infogéreur et les plateformes ITSM/ESM ; qui pilote ce type de sujets côté terrain. Sans leur connaissance fine des usages support, la Conduite du changement resterait hors-sol. C’est cette combinaison qui détermine si une transition produit réellement la valeur attendue, ou si elle se limite à un nouveau nom en bas du contrat.
Et vous, quand votre DSI a changé de prestataire ou d’outil de gestion des services, la Conduite du changement a-t-elle été pilotée dès le cadrage du contrat, ou seulement une fois la bascule technique actée ?
Repenser le pilotage des projets et la gouvernance du portefeuille d’une DSI dans le secteur de la défense
Repenser le pilotage des projets et la gouvernance du portefeuille d’une DSI dans le secteur de la défense
Notre client est un industriel du secteur de la défense. Sa DSI, organisée en plusieurs domaines, fait face à une accélération des sollicitations métier dans un environnement très contraint : cadre sécurité défense, obligations industrielles et légales, dette technique importante et delivery largement confié à des infogérants. Pour répondre à cette accélération et retisser un partenariat fort avec les entités métiers, notre client a besoin de moderniser ses pratiques de gestion de projet et nous a sollicité pour apporter un regard extérieur sur son mode de fonctionnement actuel et l’accompagner dans l’évolution de ce dernier.
Enjeux de notre mission :
A l’issue de l’analyse de l’existant, les enjeux de notre mission se sont dessinés à deux niveaux :
Au niveau opérationnel : pouvoir piloter chaque projet en fonction de sa nature, et non plus guidé par un référentiel unique de gestion de projet pensé pour des sujets prévisibles et adossé à une comitologie dense alors que tous les sujets traités par la DSI ne s’y prêtait pas
Au niveau stratégique : avoir une visibilité sur l’intégralité du portefeuille projet de la DSI et une gouvernance de ce portefeuille facilitant les prises de décisions collectives et les arbitrages entre les domaines
Ces deux axes de travail doivent permettre au client :
De prendre des décisions collégialement et non domaine par domaine sur son portefeuille projets en fonction des priorités métier et de données factuelles remontées du terrain
D’avoir une gestion de projet efficace et adaptée à la nature de chaque projet, et ainsi éviter une lourdeur de comitologie inutile
De retrouver la capacité à finir les projets engagés avant d’en commencer de nouveaux en alignement avec les entités métiers
Mission : ce que nous avons réalisé
Notre mission a consisté à accompagner le PMO, les responsables de domaine et chefs de projet, du diagnostic jusqu’à la conception de leur nouveau modèle opérationnel, en faisant évoluer leur existant plutôt que d’en faire table rase :
Diagnostic 360° de l’existant basé sur des interviews individuels, des ateliers collectifs, l’observation d’instances et des récits par les participants, pour décrire le travail tel qu’il se fait et non tel qu’il est prescrit
Restitution d’une lecture partagée du fonctionnement réel : contraintes, tensions, dynamiques soutenantes et bloquantes, leviers à amplifier et risques à éviter
Ateliers de construction de la gouvernance du portefeuille avec les responsables de domaine et le PMO : refonte de la comitologie de suivi du portefeuille, trimestrialisation des engagements et des arbitrages tout en gardant une budgétisation annuelle, réflexion sur les principes et règles nécessaires pour un arbitrage collectif
Développement d’un outil de gestion du portefeuille projet personnalisé au contexte de l’entreprise pour soutenir la démarche de visualisation unifiée du portefeuille et d’arbitrage collectif
Conception de parcours différenciés selon la nature des projets : un canal allégé pour les petits projets, un engagement ferme pour les projets compliqués, un engagement par tranches pour les projets complexes
Co-construction des Definition of Readyet Definition Of Done des projets en fonction de leur nature : simple, compliqué ou complexe
Formalisation du nouveau modèle opérationnel dans un ensemble de documents expliquant pour certains les changements et leur sens, et pour d’autres des aspects pratiques de mise en œuvre des nouveaux éléments de la comitologie
Animation d’une première instance de revue du portefeuille pour illustrer son fonctionnement et les mécanismes d’arbitrage collectif
Les autres success stories qui peuvent vous intéresser
Notre client est l’un des principaux fournisseurs européens d’assurance vie, de prévoyance et de retraite. En 2025, cette entreprise a lancé un programme sur six ans pour accélérer la transformation digitale de son SI et être en capacité de rester compétitif dans un secteur fortement concurrentiel. Pilier de la stratégie 2025-2027, ce programme est actuellement piloté de près par la direction générale. Couvrant entre autres des sujets comme l’orchestration des processus, l’IA générative, la migration vers le cloud ou encore la modernisation des systèmes mainframe historiques, et l’utilisation de ces briques SI dans l’implémentation de nouveaux cas d’usage métier, ce programme rassemble une cinquantaine d’équipes AMOA et MOE réparties entre la DSI et la Direction de la Transformation.
Pour synchroniser cet ensemble, la direction du programme a mis en place un PI Planning trimestriel dès le début du programme en l’adaptant au contexte de l’organisation. Mais ce rendez-vous s’est rapidement essoufflé.
Enjeux de notre mission :
L’enjeu principal de cette mission est de redonner une dynamique positive à ce PI Planning en répondant à la fois aux attentes des participants, mais aussi au besoin de pilotage global du programme, le tout dans un régime de contraintes assez fort :
Une organisation complexe induisant de nombreuses dépendances où plusieurs briques du programme impliquent plusieurs équipes qui peuvent elles-mêmes contribuer à plusieurs briques et aussi des projets en dehors du programme en question,
Des méthodologies de travail multiples en fonction des équipes (cycle en V, agile),
Pas de mandat à date de transformer l’organisation ou d’agiliser l’ensemble des équipes.
De manière plus détaillée, les enjeux pour notre client étaient les suivants :
Identifier et mettre en œuvre des axes d’amélioration pour redonner de la valeur au PI Planning dans la comitologie programme en place
Amener les équipes à s’engager plus sur des livrables à une échelle trimestrielle durant le PI Planning et non pas faire juste de la réconciliation de chiffres de capacité et de forecast comme c’était le cas dans les premiers PI Plannings
Enrayer le désengagement progressif des participants dans ce PI Planning
Redonner une place importante et active aux représentants métier dans ce PI Planning
Mission : ce que nous avons réalisé
Notre mission a consisté à accompagner la direction du programme, les sponsors et les principaux acteurs des briques du programme, du diagnostic jusqu’à la mise en œuvre du nouveau format, PI Planning après PI Planning :
Diagnostic 360° basé sur des interviews individuels (direction de programme, responsables de briques, chefs de projet, architectes, PMO, porteur d’enjeux métier) et l’observation terrain d’un PI Planning, amenant à une mise en évidence des forces à préserver et des recommandations d’amélioration
Co-constructiondela raison d’être du futur PI Planning et de ses critères de succès observables
Conception d’un nouveau déroulé sur-mesure permettant de changer le focus du PI Planning : passer d’une réconciliation de chiffres à une construction collective d’engagements en termes de livrables pour le trimestre à venir
Création d’un cadre de définition d’un livrable trimestriel agnostique à toute méthodologie projet et de l’outillage pour amener les équipes à définirses engagements : catalogue de patterns de découpage des livrables, management visuel des dépendances, structure de présentation des éléments en entrée et en sortie du PI Planning
Ateliers de préparation du PI Planning pour les acteurs clés des briques
Redéfinition des modalités d’intervention des représentants métiers
Intégration progressive de doers parmi les participants au PI Planning pour un engagement encore plus fiable
Animation du premier PI Planning au nouveau format et co-animation des deux suivants avec un facilitateur côté client pour une appropriation progressive
Mise en place d’un processus d’amélioration continue entre chaque PI Planning : récolte de feedback formalisée à la fin de chaque PI Planning, débrief critique à l’issue de chaque PI Planning, mise en œuvre d’actions d’amélioration pour le PI Planning suivant
Les premiers résultats :
La mission est encore en cours, mais l’accompagnement a déjà permis :
De tenir le premier PI Planning au nouveau format, avec un changement radical d’objectif moins de quatre mois après le démarrage, sans décaler le calendrier initial
D’obtenir des engagements trimestriels formulés en livrables pour une majeure partie des briques du programme
De faire adopter les outils : le modèle de définition d’un livrable et les supports d’atelier qui ont été jugés utiles
D’installer une boucle d’amélioration continue, du feedback wall au débrief puis aux ajustements, qui fait progresser le format à chaque trimestre
Les autres success stories qui peuvent vous intéresser
L’intelligence artificielle est devenue incontournable dans les discours et plans de transformation des organisations. Qu’il s’agisse des centres de services, des services d’assistance informatique, du support client ou des fonctions d’accompagnement des utilisateurs, rares sont aujourd’hui les feuilles de route qui ne comportent pas un volet IA. Chatbots, assistants virtuels, analyse prédictive, automatisation des traitements ou encore IA générative sont désormais présentés comme des leviers majeurs d’amélioration de la qualité de service et de performance opérationnelle.
Pourtant, derrière cet engouement généralisé, une question demeure : l’omniprésence de l’IA dans les plans de transformation conduit-elle réellement à son adoption par les utilisateurs et les équipes de support ?
En Juin dernier, EasyVista annonçait que 95% des entreprises intégrait de l’IA à leur processus ITSM, mais que seulement 12% trouvait l’approche mature et proactive.
Une promesse forte de création de valeur
Les bénéfices attendus de l’IA sont nombreux :
Réduction des délais de traitement
Disponibilité des services 24h/24, 7j/7 et dans la langue de prédilection de l’utilisateur.trice (contexte international).
Diminution du volume des sollicitations adressées aux équipes humaines.
Personnalisation des réponses.
Amélioration de l’expérience utilisateur grâce à l’omnicanalité
Réduction des coûts de fonctionnement.
Dans un contexte où les directions sont soumises à des contraintes budgétaires croissantes tout en devant maintenir un haut niveau de satisfaction, l’IA apparaît comme une solution particulièrement attractive.
L’IA générative renforce encore cette dynamique en offrant la possibilité de produire des réponses contextualisées, d’assister les agents en temps réel et de faciliter l’accès à la connaissance. L’IA doit ainsi permettre de montrer la valeur du service fourni en le rendant plus homogène, plus systématique et plus disponible tout en réduisant, a priori, le coût du dispositif mis en place.
De la mise en œuvre à l’adoption : un écart souvent sous-estimé
Cependant, déployer une solution d’IA ne garantit pas son utilisation effective.
De nombreuses organisations constatent que les outils mis à disposition ne produisent pas toujours les résultats attendus. Les utilisateurs continuent parfois à privilégier les canaux traditionnels de contact, tandis que les équipes opérationnelles peinent à intégrer pleinement ces nouvelles solutions dans leurs pratiques quotidiennes.
Cet écart s’explique souvent par une confusion entre déploiement technologique et adoption. Toujours selon l’enquête EasyVista, l’intégration poussée des technologies IA serait bridée, à parts égales, par des contraintes budgétaires, le manque de personnel qualifié ou des écarts dans le chemin d’intégration (ie cas d’usages peu ou mal identifiés, base documentaire inadaptée, etc)
La réussite d’un projet IA ne se mesure pas uniquement au nombre de fonctionnalités disponibles mais à sa capacité à être acceptée, comprise et utilisée durablement. Dans le plan de transformation, il faut donc dépasser les seuls aspects techniques, gouvernance et finance : il faut y ajouter un volet devant maximiser l’adoption. Il existe plusieurs approches pour cela ; chacune avec des avantages et des inconvénients.
Rassembler tous les points d’entrée et de contact vers le support au même endroit. La solution de messagerie entreprise (Teams, Slack, etc) peut être mise à contribution pour cela.
Mettre en place les briques de l’omnicanalité pour permettre une expérience sans coutures, sans regard pour le canal initial choisi
Appliquer des solutions IA de manière stratégique afin de permettre une autonomie la plus complète des utilisateurs et prioriser les zones à forte valeur ajoutée (eg ne pas remplacer un processus entier mais intégrer l’IA à des jalons spécifiques pour maximiser son apport et focaliser la valeur ajoutée des experts dans le processus)
Quelle que soit la trajectoire choisie, les sujets d’audit, de sourcing, de transition et d’accompagnement au changement seront nécessairement évoqués et viseront, à donner une vision réaliste des solutions qui peuvent être mises en place, sous quel délais et avec quelles adaptations tout en maximisant leur adoption par les utilisateurs.
Les facteurs clés de l’adoption
La confiance
La confiance constitue le premier facteur d’adoption.
Les utilisateurs doivent percevoir l’IA comme fiable, pertinente et sécurisée. Une réponse inexacte, incohérente ou difficile à comprendre peut rapidement détériorer cette confiance.
La capacité à expliquer les résultats et la transparence sur les limites de l’outil deviennent donc essentielles.
De même, montrer clairement quand les interactions sont gérées par une IA ou un humain, peut permettre aux utilisateurs une plus grande sérénité d’usage.
La simplicité d’usage
Une IA performante mais complexe à utiliser risque d’être contournée.
Les projets les plus efficaces sont souvent ceux où l’IA s’intègre naturellement dans les parcours existants sans imposer de changements excessifs aux utilisateurs.
L’expérience utilisateur doit rester au cœur de la conception et l’ergonomie de son utilisation doit être pensée dès le dimensionnement et la planification.
L’accompagnement au changement
L’introduction de l’IA modifie les habitudes de travail, les rôles et parfois les responsabilités.
Sans communication adaptée, sans formation et sans accompagnement des équipes, des résistances peuvent apparaître.
L’adoption est avant tout un enjeu humain avant d’être un enjeu technologique.
La qualité des données
Les performances d’une IA dépendent directement de la qualité des données qui l’alimentent. Des bases de connaissances obsolètes, incomplètes ou incohérentes limitent fortement la valeur apportée par les solutions déployées.
Avant d’investir dans l’IA, les organisations doivent souvent investir dans leur patrimoine informationnel. Il est fréquent de devoir, par exemple, adapter le formatage de la donnée, afin de permettre une exploitation satisfaisante par l’IA. Ces chantiers primaires, mais moins visibles, sont particulièrement chronophages. Nous accompagnons nos clients dans leur évaluation et remise en ordre de leur base documentaire.
Le rôle stratégique des consultants en transformation
Dans ce contexte, les consultants ont un rôle déterminant à jouer.
Leur mission ne consiste plus seulement à sélectionner des outils ou à optimiser des processus. Ils doivent également :
Identifier les usages créateurs de valeur.
Évaluer la maturité de l’organisation.
Concevoir des parcours utilisateurs adaptés.
Accompagner les changements de pratiques.
Mesurer l’adoption par la production d’indicateurs adaptés
Garantir une gouvernance responsable de l’IA intégrée à la gouvernance déjà en place pour le reste des outils.
Le véritable enjeu n’est plus de savoir comment déployer l’IA mais comment favoriser son appropriation par les utilisateurs.
Vers une adoption raisonnée de l’IA
L’avenir des supports aux utilisateurs ne repose probablement ni sur une automatisation totale ni sur le maintien exclusif des modèles traditionnels. Certains pan peuvent et doivent être automatisés afin de libérer de la capacité à créer de la valeur pour ce qui doit être traité selon les modèles plus traditionnels.
Les organisations les plus performantes seront celles qui sauront construire un modèle hybride où l’IA prend en charge les tâches répétitives tandis que les experts humains se concentrent sur les situations complexes, sensibles ou à forte valeur ajoutée.
Dans cette perspective, l’IA devient un outil d’augmentation des capacités humaines plutôt qu’un substitut. Elle réduit les coûts alloués aux tâches plus simples sans occulter le besoin de support humain, adaptés, empathique et capable de gérer les situations plus complexes.
L’omniprésence de l’IA dans les plans de transformation des supports aux utilisateurs traduit une conviction forte : celle de son potentiel pour améliorer la qualité de service et l’efficacité opérationnelle. Toutefois, le succès de ces initiatives dépend moins de la technologie elle-même que de sa capacité à être adoptée par les utilisateurs et les équipes.
La question n’est donc plus « Faut-il intégrer l’IA ? » mais « Comment créer les conditions d’une adoption durable et créatrice de valeur ? ». La réponse réside dans un équilibre subtil entre innovation technologique, expérience utilisateur, qualité des données et accompagnement humain.