L’adoption de l’IA est un indicateur de vanité

Chris Garrett est vice-président des technologies gérées et des opérations de sécurité chez Novatech, un fournisseur de services gérés. Il est également l’auteur de Se développer ou vendre.

Nous nous sommes entretenus avec Chris pour en apprendre davantage sur ses flux de travail liés à l’IA et pour comprendre comment l’IA transforme le secteur. Voici ce qu’il avait à dire.

Traduire les systèmes en valeur financière

Je dirige les activités de technologies et de sécurité gérées chez Novatech, un fournisseur de services gérés détenu par Perpetual Capital Partners. Le titre indique vice-président. Le travail, lui, est plus simple à décrire. Je suis responsable de faire en sorte que la technologie rapporte de l’argent à l’entreprise au lieu de le lui faire perdre discrètement.

Le chemin parcouru n’a pas été linéaire. J’ai commencé dans les opérations, là où les systèmes tombent en panne et où quelqu’un doit prendre en charge la résolution. J’ai travaillé au service d’assistance, puis dans l’infrastructure et enfin dans la sécurité. Ce sont les environnements où l’écart entre les promesses d’un fournisseur et le comportement réel d’un réseau devient votre problème à deux heures du matin. Cette base m’a appris une leçon qui reste valable depuis. La technologie n’est pas une fin en soi. L’objectif est de protéger les revenus, d’évaluer correctement les risques et d’éliminer les temps d’arrêt avant même qu’un client ne les ressente.

Ensuite, j’ai appris à traduire. Les ingénieurs parlent en systèmes et les dirigeants parlent en dollars, et la plupart des responsables technologiques choisissent une langue au détriment de l’autre public. J’ai bâti ma carrière dans cet espace intermédiaire, en transformant la latence, l’exposition et l’architecture en langage de marge et de continuité : l’informatique comme multiplicateur, jamais comme centre de coûts. Cette manière de présenter les choses a changé les conversations auxquelles j’ai participé et les décisions que j’ai contribué à façonner.

Le terrain évolue à nouveau. L’IA n’est pas simplement le prochain outil de la pile technologique. Elle modifie la signification du levier, ceux qui le détiennent et la vitesse à laquelle les capacités se démultiplient. La plupart des organisations répondent par du bruit. Elles lancent des projets pilotes qui ne prouvent rien et rédigent des politiques pour gérer l’anxiété plutôt que les risques, tandis que les fournisseurs vendent l’inéluctabilité à des acheteurs qui n’ont pas fait leurs calculs.

Mon intérêt est plus ciblé et plus difficile à simuler. Où l’IA fait-elle réellement évoluer les chiffres ? Qu’expose-t-elle qui était déjà fragile ? Quelles compétences exige-t-elle que la plupart des équipes ne possèdent pas encore ? Je l’aborde comme tout le reste : les faits plutôt que le battage médiatique, les résultats plutôt que le consensus, la couche des systèmes plutôt que le récit de surface.

Les complexités du poste

Novatech est un fournisseur de services gérés détenu par Perpetual Capital Partners depuis septembre 2024. Nous sommes une entreprise de services rentable issue d’une acquisition, avec pour mandat d’augmenter la marge et les revenus liés à la sécurité tout en maintenant la qualité de prestation qui nous a permis de gagner notre clientèle.

La division opère aux côtés des activités de technologies gérées, de bureaux gérés et de répartition sur le terrain, en réalisant le travail qui permet aux opérations des clients de fonctionner et de rester protégées. Mon équipe compte 68 ingénieurs et analystes répartis entre le service d’assistance, l’infrastructure et une pratique dédiée à la sécurité, au service de 400 environnements clients.

L’architecture ne repose pas sur un seul produit ; elle est multilocataire. Nous exploitons des dizaines d’environnements clients distincts, chacun avec sa propre combinaison d’infrastructures sur site, de Microsoft 365, d’Azure, d’AWS et de Google Cloud, ainsi que des réseaux hybrides que nous n’avons pas toujours conçus, mais dont nous avons désormais la responsabilité. Cette diversité crée de la complexité. Une modification de routine pour un client peut représenter un risque de production pour un autre. La discipline consiste à gérer ce parc selon une norme unique de fiabilité et de niveau de sécurité, sans forcer chaque client à entrer dans le même moule.

Notre modèle de déploiement est géré et prioritairement à distance, avec le soutien de la répartition sur le terrain pour les interventions nécessitant une présence sur site. Nous surveillons, appliquons les correctifs et assurons la défense en continu. Nous évaluons notre performance selon la disponibilité, le temps de réponse et la rapidité avec laquelle nous contenons les incidents de sécurité avant que les clients ne les subissent.

Comment l’IA transforme les processus de prise de décision technique — sans les prendre en charge

Ma philosophie fondamentale consiste à « entourer l’ingénieur d’IA » afin de tirer le meilleur parti des deux mondes. Il ne s’agit pas de réduire les effectifs ; l’équipe accomplit plutôt davantage de travail, et de meilleure qualité, grâce à des outils d’assistance.

L’IA prend désormais en charge les tâches à haut volume pour lesquelles un évaluateur humain constituait toujours le goulot d’étranglement sans jamais représenter la valeur ajoutée. Par exemple, le triage des alertes de sécurité passe d’abord par une couche d’IA, car demander à un analyste SOC de lire manuellement dix mille événements à faible signal coûte cher et produit de moins bons résultats que le modèle.

Nous utilisons l’IA de manière similaire pour analyser les journaux lors des investigations, rédiger une première version de la documentation et des procédures d’exploitation, et résumer l’environnement d’un client avant un examen. L’ingénieur arrive ainsi informé plutôt que sans préparation. Dans tous ces cas, l’IA accélère l’analyse ; elle ne prend pas la décision.

La décision reste humaine, et cette limite est délibérée. Les décisions d’architecture concernant l’environnement d’un client restent humaines, car le modèle optimise la réponse techniquement irréprochable. Une véritable décision prend en compte le budget, la tolérance au risque du client et ce que son équipe peut réellement exploiter après notre départ.

La réponse aux incidents reste humaine au niveau du commandement. L’IA peut mettre en évidence ce qui s’est passé, mais les choix de confinement ont des conséquences commerciales, une exposition juridique et un impact sur la confiance des clients. Je ne confierai pas le jugement sous pression à un outil qui ne peut pas être tenu responsable du résultat. La revue de sécurité finale avant validation reste humaine pour la même raison. Le modèle excelle à repérer les schémas connus, mais il est aveugle aux problèmes inédits qui comptent vraiment.

Un processus concret de triage des alertes de sécurité

Examinons plus en détail le triage des alertes de sécurité, car il s’exécute quotidiennement et montre clairement où l’IA intervient et où l’humain prend le relais.

Le processus commence par un volume qu’aucun humain ne peut ni ne devrait traiter manuellement de manière constante. Dans l’ensemble du parc de clients, notre supervision génère des dizaines de milliers d’événements par jour, dont la plupart sont du bruit. Avant l’IA, un analyste traitait une file d’attente, tandis que le véritable signal restait enfoui sous les échecs de connexion et les anomalies bénignes. Les problèmes importants étaient pris en charge tardivement, car l’analyste devait se frayer un chemin dans le bruit pour les trouver.

La couche d’IA traite d’abord ce flux brut. Elle regroupe les événements associés, élimine les faux positifs évidents par rapport aux schémas connus comme légitimes, met en corrélation des activités dans un environnement client que l’humain considérerait comme déconnectées, puis classe les éléments restants selon leur ressemblance avec une véritable intrusion. L’analyste ne reçoit pas un flot ininterrompu de données. Il reçoit plutôt une courte liste ordonnée, accompagnée du contexte, des systèmes affectés nommément désignés et d’une explication explicite de la raison pour laquelle chaque élément a été remonté. Le modèle effectue la lecture initiale, mais ne prend aucune décision.

L’analyste ouvre cette liste, et le travail humain commence. Il enquête sur le fil suspect, tandis que l’IA l’aide à nouveau en résumant les journaux pertinents et la chronologie, ce qui lui permet de reconstituer les événements en quelques minutes au lieu d’une heure. Le jugement reste entre les mains de la personne. S’agit-il d’une compromission réelle ou d’une modification autorisée qui semble suspecte ? Le schéma correspond-il à quelque chose d’inédit que le modèle ne signalerait pas ? Le modèle accélère l’examen des éléments de preuve ; l’analyste prend la décision.

Lorsqu’un événement réel survient, le confinement reste une décision de commandement humaine. L’analyste, ou le responsable senior d’astreinte pour les incidents graves, décide d’isoler un hôte, de désactiver un compte ou de déconnecter un client. Ces choix entraînent des coûts commerciaux, une exposition juridique et des conséquences sur la confiance des clients, et aucun outil ne peut être tenu responsable de ces décisions. L’IA peut vous dire ce qui s’est passé, mais elle ne choisit pas notre réponse sous pression.

Après le confinement, l’IA rédige le dossier de l’incident, la chronologie, les actions entreprises et le résumé destiné au client. Ce brouillon fait gagner beaucoup de temps par rapport à une rédaction commencée sur une page blanche. Il n’est pas envoyé avant qu’un ingénieur ne le corrige et ne le signe. Un rapport erroné mais bien présenté est pire que l’absence de rapport, et une procédure officielle rédigée par l’IA sans responsable humain créerait une responsabilité que nous avons décidé de ne jamais laisser apparaître sous notre supervision.

La boucle se termine par une étape que la plupart des équipes négligent. Nous examinons par échantillonnage ce que l’IA a écarté, et pas seulement ce qu’elle a remonté, puis nous réinjectons ces erreurs pour affiner le passage suivant. Cette discipline d’échantillonnage empêche l’automatisation de créer un biais. Un outil qui rend les analystes plus rapides les rend également complaisants si personne ne vérifie les éléments qu’il écarte.

Pourquoi les entreprises doivent assainir leurs autorisations avant d’intégrer l’IA

J’ai également mis en place une étape de gouvernance pour Microsoft Copilot.

Auparavant, Copilot semblait être une amélioration de la productivité, et les clients le considéraient comme un simple interrupteur à activer. Le problème est que Copilot hérite des accès existants de l’utilisateur. La plupart de nos clients accumulaient depuis des années une prolifération des autorisations : des sites SharePoint ouverts, des lecteurs partagés que personne n’avait nettoyés et des fichiers techniquement accessibles, mais pratiquement invisibles. Dès lors que vous donnez à un employé un outil qui recherche dans tout ce à quoi il peut accéder, le contenu invisible devient un résultat de recherche. Un employé débutant pouvait poser une question en langage courant et faire apparaître des données salariales ou une présentation du conseil d’administration qui ne lui était jamais destinée. Personne ne s’était occupé des autorisations, mais l’exposition était réelle et existait depuis des années.

J’ai créé une évaluation obligatoire de l’état de préparation qui s’exécute avant l’activation de Copilot pour quiconque. Nous cartographions les accès effectifs, repérons les contenus trop largement partagés et corrigeons d’abord le modèle d’autorisation. Le client valide ce à quoi ses propres employés peuvent accéder avant la mise en service d’une seule licence d’IA. Nous avons transformé une demande de fonctionnalité en déploiement gouverné, assorti d’une condition préalable stricte.

Chris souligne

Dès que vous donnez à un employé un outil qui recherche dans tout ce à quoi il peut accéder, le contenu invisible devient un résultat de recherche.

Les gains de l’IA s’accompagnent d’un coût en matière de discipline

Du côté de la sécurité, la couche de triage des alertes a réduit d’environ 70 % le volume que les analystes traitent manuellement. Le délai moyen de prise en compte d’une véritable alerte est passé de plusieurs heures à quelques minutes pendant les périodes creuses, car les analystes n’ont plus à fouiller le bruit pour trouver les événements importants. C’est notre réussite la plus nette. Le coût d’une erreur est faible : un humain vérifie de toute façon la liste restreinte, et le modèle excelle dans la détection de tendances, une tâche que les humains accomplissent mal jour après jour.

Le travail de préparation de CoPilot a produit un résultat d’une autre nature. Nous avons trouvé des données exposées dans chaque évaluation menée, des problèmes antérieurs à l’IA qui seraient restés enfouis. C’est bon pour la sécurité et bon pour le chiffre d’affaires.

Les gains liés à la rédaction sont réels, mais moins importants que ne le laisse entendre le battage médiatique. La documentation et les premières versions de procédures opérationnelles assistées par l’IA ont réduit de plus de moitié le temps nécessaire pour produire une première version. Un ingénieur doit toujours corriger le travail : le gain se situe donc dans le problème de la page blanche, et non dans le produit final.

Le mode d’échec qui nous a coûté le plus cher a été le biais d’automatisation. Au début, quelques analystes ont commencé à faire excessivement confiance au triage de l’IA et ont laissé passer des éléments qu’ils auraient dû examiner. Nous l’avons détecté lors d’une revue, mais cela m’a appris qu’un outil qui rend les gens plus rapides les rend aussi plus négligents si on le laisse faire ; la solution relevait du processus, pas de la technologie. Nous échantillonnons désormais ce que l’IA écarte, et pas seulement ce qu’elle fait remonter.

En bref, l’IA nous a fait gagner de la vitesse partout, mais nulle part du discernement. Chaque gain s’est accompagné d’un coût en matière de discipline pour empêcher les gens de lui accorder une confiance supérieure à ce qu’elle avait mérité.

Comment l’IA améliore la production, mais pas les compétences

Voici quelque chose dont personne ne veut parler : l’IA n’a pas rendu les gens plus compétents. Elle leur a permis de louer une apparence de compétence et de prétendre qu’il s’agissait de la réalité.

Appelez cela « louer une voix ». Une personne produit un résultat qu’elle n’aurait pas pu produire seule — du code, une justification d’architecture, une politique de sécurité ou, par exemple, une analyse destinée à un client — et ce résultat paraît fluide et faisant autorité. La fluidité est réelle. Les mots empruntent la compétence sous-jacente, laquelle disparaît dès que le modèle cesse de saisir du texte. La personne possède le résultat, mais pas la compréhension. Cet écart reste invisible jusqu’à ce que quelque chose se brise ; à ce moment-là, il devient l’élément le plus bruyant de la pièce.

Voici un exemple : un ingénieur débutant déploie une correction générée par l’IA qui fonctionne dans la démonstration, puis se trouve incapable de l’expliquer lors d’un incident trois semaines plus tard. Un ingénieur senior doit alors rétroconcevoir une solution que personne dans l’équipe n’a écrite. La vitesse obtenue en amont a entraîné un coût en aval, et ce coût était plus élevé parce que la surface fluide avait retardé le moment où quelqu’un vérifierait le fond.

L’attente déçue était celle de l’effet de levier. La promesse était que l’IA multiplierait les capacités des personnes compétentes. En réalité, elle aplanit la différence visible entre quelqu’un qui sait et quelqu’un qui sait formuler des requêtes, et cet aplatissement coûte cher, car les deux produisent un travail d’apparence identique et des résultats radicalement différents sous charge.

Le seul usage durable de l’IA consiste donc à ce qu’une personne qui possède déjà les compétences nécessaires l’utilise pour travailler plus vite, car cette personne peut repérer les erreurs dans le résultat. Donnez le même outil à quelqu’un qui emprunte entièrement ces compétences et vous n’aurez pas augmenté la capacité. Vous aurez ajouté une production assurée d’elle-même, sans personne de responsable derrière elle.

Pourquoi les collaborateurs débutants restent nécessaires avec l’IA

Chris souligne

Une manière d’éviter d’en arriver là consiste à déployer l’IA de façon plus ciblée, en la méritant niveau par niveau. Les mêmes gains, sans réduire discrètement les ressources de la filière qui forme les seniors grâce auxquels cette approche reste sûre.

C’est le modèle que j’ai utilisé pour bâtir chaque organisation de services que j’ai dirigée : placer les capacités des débutants sous la supervision de seniors, laisser le volume de travail s’écouler vers les personnes compétentes les moins coûteuses, et développer la pyramide à mesure que la demande augmente.

L’IA a absorbé la base de la pyramide. Le travail que je confiais auparavant aux débutants — premier triage, lecture des journaux, rédaction de procédures opérationnelles, tickets courants — correspond exactement aux tâches que le modèle accomplit désormais plus rapidement et à moindre coût qu’une personne en cours d’apprentissage. Le calcul des effectifs qui dépendait d’une large base de travail volumineux et peu coûteux ne tient plus, car ce travail volumineux ne nécessite plus de personne.

Mais le niveau junior n'a jamais été uniquement une main-d'œuvre bon marché. C'était le terrain d'entraînement. Les personnes sur lesquelles je m'appuie aujourd'hui en tant que seniors le sont devenues en traitant des milliers de tickets à faible enjeu et en développant leur jugement, erreur après erreur. Supprimez cette marche, et vous n'aurez pas seulement modifié la structure des coûts de cette année. Vous aurez cessé de former les ingénieurs seniors dont vous aurez besoin dans cinq ans, et vous ne ressentirez ce manque que lorsqu'il sera coûteux à combler.

Une façon d'éviter d'en arriver là consiste à déployer l'IA de manière plus ciblée, en progressant palier par palier. Les mêmes gains, sans réduire discrètement les moyens de la filière qui produit les seniors grâce auxquels cette démarche reste sûre.

Je ne l'ai pas fait, alors je reconstruis l'échelle. Nous conservons les juniors, mais pas pour absorber un volume que le modèle gère déjà. Ils sont là pour développer la seule chose que l'IA ne peut pas leur apporter : le jugement nécessaire pour savoir quand sa réponse assurée est erronée. Cela signifie une exposition délibérée aux problèmes difficiles dès le début, du temps consacré par les seniors à l'enseignement plutôt qu'à la délégation, et une base plus réduite et plus performante que ce que l'ancienne logique économique aurait constitué.

Pourquoi l'adoption est un indicateur superficiel

Le déploiement échoue au niveau humain, pas au niveau technologique. J'ai dû faire marche arrière sur presque tout parce que j'avais inversé les priorités.

J'ai traité le lancement comme un problème de capacités. Choisir les outils, prouver qu'ils fonctionnent, donner accès aux équipes, mesurer l'adoption. L'adoption a augmenté, et j'y ai vu un succès. En réalité, j'observais des personnes prendre l'habitude de faire confiance à des résultats qu'elles n'avaient pas appris à remettre en question, et cette confiance excessive est un symptôme précoce d'échec, pas une preuve de réussite.

Puisque nous en parlons, j'aurais dû refuser de mesurer l'adoption. C'est un chiffre superficiel qui m'a orienté dans la mauvaise direction. L'indicateur important était de savoir si les personnes vérifiaient les résultats avant de leur faire confiance, et c'est plus difficile à comptabiliser ; j'ai donc suivi la mesure la plus simple. Mesurer l'utilisation récompensait précisément le comportement à l'origine du travail désordonné : les personnes s'appuyaient davantage et plus rapidement sur l'outil, avec moins d'esprit critique.

Aujourd'hui, je mesurerais plutôt la vérification et le travail à refaire, et je ne laisserais plus jamais un graphique d'utilisation tenir lieu d'amélioration du travail.

Pourquoi les CTO doivent relier chaque décision en matière d'IA aux chiffres de l'entreprise

Voici mes conseils :

1. La gouvernance d'abord. Ce n'est pas passionnant et cela ne suscitera pas l'enthousiasme des adeptes du FOMO comme les derniers modèles de pointe, mais c'est une nécessité absolue. Encadrez l'ensemble du périmètre avant de le déployer et de le développer. La plupart des problèmes graves que j'ai vus provenaient de CTO qui déployaient l'IA pour gagner en rapidité et rédigeaient la gouvernance après coup. Inversez cet ordre.
2. Cessez d'acheter de la maturité et commencez à acheter des capacités vérifiables. La moitié des solutions d'IA présentées par les fournisseurs ne font qu'envelopper une API, vendue comme une compétence maîtrisée en interne. Demandez à chaque fournisseur de vous montrer la solution en fonctionnement sur un problème qui ne figure pas dans sa démonstration, et demandez à vos propres équipes de faire de même.
3. Protégez les personnes qui savent déjà. L'effet de levier n'est réel que lorsqu'il est entre les mains de quelqu'un capable de détecter les erreurs du modèle. Investissez dans ce jugement, mesurez-le et refusez de laisser l'aisance dans la formulation des requêtes le remplacer dans votre organigramme.
4. Reliez chaque décision en matière d'IA à un chiffre auquel l'entreprise accorde déjà de l'importance. Protégez le chiffre d'affaires, évaluez le risque et rendez du temps aux personnes qui accomplissent un travail utile. Les CTO qui présentent l'IA comme une initiative technologique devront se battre pour obtenir un budget chaque trimestre. Ceux qui la présentent comme une question de marge et de risque seront consultés dans des salles où l'on prenait autrefois des décisions sans eux. L'argument technique convainc rarement un dirigeant ; les calculs de résultat et pertes, eux, y parviennent.
5. Faites preuve de discipline. Déployez l'IA là où une personne reste responsable du résultat, éloignez-la des postes où le résultat ne tolère aucune erreur et auditez ce qu'elle écarte, pas seulement ce qu'elle remonte. Le marché récompense actuellement la rapidité et passera les prochaines années à réévaluer les équipes qui ont confondu aisance et compétence. Construisez votre organisation de façon à ne pas en faire partie.

Suivez-nous

Vous pouvez suivre le travail de Chris Garrett sur LinkedIn. Et découvrez son dernier livre, Développer ou vendre.

D’autres entretiens avec des experts sont à venir sur le club des CTO !