« À partir de maintenant, nous sommes en mode priorité à l’IA. » Cette phrase, vous l’avez sans doute entendue dans une réunion, lue dans une note interne ou croisée sur LinkedIn. Elle sonne bien. Elle donne le sentiment d’être dans le bon train, celui qui ne s’arrête pas. Et pourtant, un responsable de la sécurité vient de la comparer à une vieille connaissance des DSI : la stratégie « priorité au cloud », qui, il y a une dizaine d’années, avait lancé les entreprises dans une ruée vers le cloud… avant de leur laisser, en guise de cadeau, une gouvernance en lambeaux, des failles de sécurité et des factures qui donnent le vertige.
Son constat tient en une formule : soyez « IA intelligent », pas seulement « priorité sur l’IA ». Pas pour freiner, mais pour durer. Décortiquons cette idée avec des explications simples, pour que vous puissiez la reprendre dans votre entreprise, votre équipe ou votre association.
| 📘 Définitions pour les débutants Axé sur l’IA ou AI-first : faire de l’intelligence artificielle la priorité par défaut de l’organisation. Adoption de l’IA ou AI-enabled : être prêt pour l’IA (outils approuvés, données organisées, garde-fous de base). C’est l’étape d’avant. IA Intelligent ou AI-smart : adopter l’IA vite mais dans le bon ordre, avec des fondations solides. |
Le précédent : quand le cloud est passé de « priorité » à « intelligent »
Pour comprendre l’argument, il faut remonter un peu. En 2011, le gouvernement fédéral américain lance une politique « Priorité au Cloud » : pour tout nouveau besoin informatique, on regarde d’abord le cloud. Résultat : une adoption rapide, mais pas toujours réfléchie. En juin 2019, le Bureau de la gestion et du budget (OMB) publie la stratégie « Cloud Intelligent », qui recadre la démarche.
Que change-t-elle ? Elle affirme que le cloud n’est pas automatiquement la meilleure réponse : les agences doivent évaluer leurs besoins, faire le tri dans leurs applications avant de migrer (supprimer celles qui sont obsolètes ou redondantes) et peser les besoins de la mission, les contraintes techniques, les coûts et les risques de cybersécurité. Le message n’était donc pas « ralentissez », mais « réfléchissez avant de foncer ».
| 💡 Nuance : Ed Kandel, architecte principal en sécurité d’entreprise, affirme que la « priorité au cloud » a « fini par virer au cauchemar en matière de gouvernance ». C’est son analyse personnelle : la stratégie Cloud Intelligent, elle, parle surtout de rationalisation des applications et de choix adaptés à chaque besoin. Le parallèle avec l’IA est une thèse, pas une vérité démontrée. |
L’image à retenir : un aéroport, pas un décollage sauvage
Pour vulgariser, prenons un aéroport. La priorité à l’IA, c’est tout le monde qui veut décoller maintenant, sans piste balisée, sans tour de contrôle, sans savoir qui pilote quoi. L’AI Intelligent, c’est le même désir de décoller, mais avec de vraies procédures : on sait qui a le droit d’aller où, on contrôle avant l’embarquement, on nomme un commandant de bord, et on vérifie que la ligne mérite encore d’exister.
Ce n’est pas un frein : c’est ce qui permet de faire décoller beaucoup d’avions sans catastrophe. Voici comment l’article structure cette idée : un socle (le contexte), un point de contrôle à l’entrée et quatre piliers.
| Élément | Dans l’article | Dans l’aéroport |
| Socle | Le contexte : ce à quoi la solution a droit | Le plan de vol autorisé |
| Point de contrôle | Pertinence technique et métier | Enregistrement et contrôle de sécurité |
| Pilier 1 | Le passage à l’échelle | Procédures standard pour chaque vol |
| Pilier 2 | La sécurité | Tour de contrôle et portiques |
| Pilier 3 | Gouvernance et conformité | Le commandant de bord, identifié |
| Pilier 4 | La valeur métier | La ligne est-elle encore rentable ? |
Le socle : définir le « contexte » de chaque solution
Le mot est abstrait, l’idée est simple : à quoi cet outil d’IA précis a-t-il le droit d’accéder ? Pas « à ce que permet le compte technique qu’il utilise », mais à ce qu’on a décidé, explicitement et volontairement, qu’il pouvait toucher. Trois questions concrètes :
- Quelles données cette solution peut-elle lire, et où sont-elles stockées ?
- Quels systèmes peut-elle solliciter, et quelles actions peut-elle y faire ?
- Pour le compte de qui agit-elle, et ses droits correspondent-ils à ceux de cette personne ou de cette équipe ?
| 📘 Exemple concret : Une équipe RH branche un assistant IA sur sa messagerie et son dossier partagé pour résumer des candidatures. Sans contexte défini, l’assistant hérite des droits de l’employé qui l’a créé : il peut donc aussi lire des fichiers de paie. Avec un contexte défini, on le limite au seul dossier « candidatures », en lecture seule. (Exemple illustratif fictif.) |
Le point de contrôle : « pertinence technique et métier »
Avant même de parler des piliers, l’auteur propose un passage obligé : toute solution d’IA doit d’abord exposer ce qu’elle sait faire techniquement, les données et autorisations qu’elle utilise, et la valeur métier qui justifie cette exposition. Ce même point de contrôle peut aussi accueillir des vérifications sur le fournisseur, les risques, la conformité, le juridique et la sécurité. C’est le contrôle des passagers avant d’entrer en zone d’embarquement.
Pilier 1 : le passage à l’échelle
Une solution approuvée dans une équipe ? Très bien. Mais si les dix équipes suivantes doivent réinventer la gouvernance chacune de leur côté, deux scénarios guettent : tout recommencer à zéro… ou contourner les règles pour aller plus vite. Le remède : des modèles de référence réutilisables (architecture, modèle d’accès, modèle de demande d’approbation) pour chaque catégorie de solution, et un suivi central de qui utilise quoi.
Sans oublier les coûts : orienter chaque tâche vers le modèle le plus adapté plutôt que toujours le plus grand, mettre en cache les requêtes répétées, et surveiller la consommation de jetons (l’unité de facturation des modèles) et les coûts d’inférence avant la flambée, pas après.
Pilier 2 : la sécurité
C’est la couche des contrôles techniques : ceux qui empêchent une solution approuvée de devenir une porte d’entrée. On insiste sur quatre évolutions.
L’IA fantôme a changé de visage
Hier, le « shadow IT » (les logiciels non autorisés), c’était un abonnement SaaS souscrit en douce. Aujourd’hui, c’est un serveur MCP ou un connecteur qu’un employé branche lui-même sur Jira, une base interne ou SharePoint. Ou encore, des personnes sans formation de développeur qui utilisent des outils comme Cursor pour bâtir et mettre en ligne des applications entières, avec l’idée de « les faire relire plus tard ».
| 📘 C’est quoi un serveur MCP ? Le Model Context Protocol (MCP) est un standard ouvert qui permet à un assistant IA de dialoguer avec des outils et des données externes (messagerie, tickets, bases de données) selon une « prise universelle ». Pratique… mais chaque prise est aussi une porte. Un serveur MCP « fantôme » est un serveur branché sans validation de l’équipe de sécurité. |
Un nouveau type de risque : l’action
Avec un simple chatbot, le pire scénario est une réponse déplacée. Avec un agent relié à des outils, l’IA peut lire, écrire, supprimer, déclencher des processus. Le modèle de menace n’est plus le même : on ne redoute plus seulement ce qu’elle dit, mais ce qu’elle fait. Les principes de moindre privilège (donner juste les droits nécessaires) et de périmètre limité deviennent centraux.
Chaque agent est une identité non humaine
Chaque agent, serveur MCP ou intégration reçoit ses propres identifiants et permissions : c’est une nouvelle identité non humaine. Sans gestion de son cycle de vie (création, suivi, retrait), il finit oublié, avec ses accès toujours actifs. Nous en avons parlé dans notre décryptage sur les agents IA orphelins .
Les pratiques à mettre en œuvre dès maintenant
- Recenser tous les serveurs MCP et connecteurs IA utilisés, approuvés ou non.
- Faire passer le trafic IA par une passerelle MCP : un point de passage unique où l’on applique l’authentification, le périmètre et la limitation du débit, plutôt que des branchements au coup par coup. Pensez à un guichet unique à la frontière.
- Appliquer le moindre privilège à chaque outil appelable par un agent.
- Journaliser les actions des agents, pas seulement leurs réponses.
- Acheter avec discernement les solutions de sécurité dédiées à l’IA (AI-SPM) : leur valeur par rapport aux outils existants reste inégale, selon l’auteur. Un vrai problème d’abord, l’effet de mode ensuite.
Les pratiques émergentes
- Étendre la prévention des fuites de données (DLP) aux agents qui héritent des permissions d’un utilisateur : ils peuvent déplacer des données aussi facilement que lui, souvent plus vite et à plus grande échelle.
- Inscrire chaque agent dans l’inventaire des actifs (CMDB) comme entité à part entière, avec un périmètre, un responsable et des permissions.
- Sécuriser les échanges entre agents, y compris quand l’un agit « pour le compte » d’un autre, avec des permissions délimitées et traçables.
Pilier 3 : gouvernance et conformité
Si la sécurité répond à « comment on se protège ? », la gouvernance répond à « qui est responsable ? ». C’est la couche la plus souvent négligée, parce que son absence ne provoque aucune panne visible… jusqu’au jour où un audit, un incident ou un régulateur demande des comptes.
- Un responsable nommé pour chaque solution approuvée. On ne peut pas supposer que le créateur continuera de la surveiller.
- Un suivi des obligations (localisation des données, règles sectorielles, politiques internes), à revérifier quand l’usage évolue.
- La prolifération de fournisseurs : plusieurs équipes qui souscrivent chacune un assistant différent (Copilot, Gemini, Claude…) pour un même besoin, ça ne renforce pas la résilience, ça gonfle les dépenses et la surface de risque. Le multi-fournisseur est légitime s’il est délibéré.
- La prolifération d’infrastructures : même logique pour les charges de travail IA dispersées sur plusieurs clouds par simple habitude des équipes.
- Une recertification périodique (pratique émergente) pour confirmer que le périmètre, le responsable et la conformité restent valables.
Pilier 4 : la valeur métier
Dernière question, et non la moindre : pourquoi cette solution existe-t-elle ? La valeur qui la justifiait au départ peut s’éroder : les usages changent, les systèmes voisins évoluent, le problème initial se transforme. Une solution d’IA qu’on ne réexamine jamais devient une ligne aérienne qui vole à vide, longtemps après que sa raison d’être s’est évaporée.
- Transformer l’existant avec de l’IA quand le besoin et la valeur sont démontrés, plutôt que tout remplacer.
- Ne passer à des systèmes « IA-natifs » que si le retour sur investissement, l’importance métier et l’évolutivité le justifient, avec les mêmes exigences de contexte, de sécurité et de gouvernance.
- Réévaluer la valeur au même rythme que le contexte, et retirer ou redéfinir ce qui n’a plus de justification.
L’argument central : la gouvernance, c’est de la vitesse
Il ne s’agit pas d’un argument de conformité, mais de rapidité. Les organisations qui posent dès le départ le contexte, le passage à l’échelle, la sécurité et la gouvernance avancent plus vite, parce qu’elles ne passent pas l’année suivante à réparer les raccourcis de l’année précédente. L’on parle de dette opérationnelle : celle qu’on accumule « au nom de la rapidité » et qu’on rembourse ensuite avec des intérêts.
Par où commencer, très concrètement ? Cinq gestes
- Faire l’inventaire : quels outils d’IA, quels connecteurs, quels agents sont utilisés aujourd’hui, avec ou sans autorisation ?
- Créer un point de contrôle simple : un formulaire d’une page (à quoi ça sert, quelles données, quelle valeur).
- Nommer un responsable pour chaque solution.
- Offrir une alternative approuvée : si on n’offre aucun outil sanctionné, les équipes iront en chercher un sans permission.
- Prévoir une revue régulière : réévaluer valeur, périmètre et responsable, au moins une fois par an.
Ce que nous retenons, c’est que la vraie opposition n’est pas vitesse contre prudence. Elle est entre vitesse durable et vitesse à crédit. La « priorité sur l’IA » est un bon instinct, l’auteur le reconnaît lui-même : attendre la gouvernance parfaite n’est pas une option. Mais un slogan ne remplace pas des fondations. Et une grande partie des bonnes pratiques citées (inventaire, responsable nommé, moindre privilège) ne demandent ni budget colossal ni outil miracle : juste de l’organisation.
Et vous, qu’en pensez-vous ? Quelques questions pour lancer la discussion :
- Votre entreprise ou votre équipe est-elle plutôt AI-first, AI-enabled ou AI-smart ? Sur quoi vous basez-vous ?
- Avez-vous déjà branché un outil d’IA sur vos données de travail sans passer par un processus d’approbation ?
- Un point de contrôle obligatoire freine-t-il l’innovation, ou l’accélère-t-il à moyen terme ?
- Qui devrait être responsable d’un agent IA : son créateur, son manager ou la sécurité ?
Partagez votre expérience en commentaire.
Source : CIO