Agents, RAG, souveraineté : ce que ça veut vraiment dire (Glossaire de l’IA)
Les mots ont envahi les réunions. LLM, agents, RAG, orchestration, fine-tuning – tout le monde les utilise, peu de gens les définissent de la même façon. Ce glossaire n’est pas un dictionnaire. C’est une mise au point : voilà ce que ces termes recouvrent concrètement, où ils s’appliquent, et où on vous raconte des histoires.
Cette édition complète la précédente sur trois points qui manquaient : les mécanismes techniques qui font qu’un agent agit vraiment (function calling, garde-fous, évaluation), le cadre réglementaire qui s’impose désormais aux projets IA (AI Act, RGPD, shadow IA), et un terme qu’on cite sans jamais l’expliquer – le Cloud Act.
Les fondations
Qu’est-ce qu’un LLM – et pourquoi « grand » ne veut pas dire « meilleur » ?
LLM signifie Large Language Model – modèle de langage de grande taille. Concrètement : un système entraîné sur des quantités massives de texte pour prédire, mot après mot, la suite la plus probable d’une séquence. C’est de là que vient sa capacité à rédiger, résumer, traduire, coder, raisonner en langage naturel.
« Grand » désigne la taille du modèle – le nombre de paramètres, c’est-à-dire les variables internes ajustées pendant l’entraînement. GPT, Claude, Gemini, Llama, Mistral sont tous des LLM, dans des versions qui évoluent en permanence. Leurs tailles et architectures diffèrent, ce qui explique des performances très variables selon les tâches.
Ce que « grand » ne garantit pas : la précision sur votre métier, la connaissance de vos documents internes, la conformité à vos contraintes réglementaires. Un LLM de pointe interrogé sur votre base contractuelle sans accès à vos données répond avec ce qu’il a appris à l’entraînement – pas avec votre réalité. C’est le premier malentendu qu’on dissipe systématiquement en début de projet.
Tokenisation – ce que le modèle lit vraiment
Un LLM ne lit pas des mots. Il lit des tokens – des fragments de texte qui peuvent être un mot entier, une syllabe, un signe de ponctuation, ou une séquence de caractères fréquente. « Incompréhensible » sera découpé en plusieurs tokens. « IA » en sera un seul.
Pourquoi ça compte concrètement : les coûts d’API sont facturés au token, pas au mot. La limite de contexte d’un modèle est exprimée en tokens. Et la façon dont un document est tokenisé influence ce que le modèle en comprend – un tableau mal formaté produit une séquence de tokens incohérente, ce qui dégrade la qualité de la réponse indépendamment de la puissance du modèle.
Un détail qu’on découvre souvent trop tard : chaque famille de modèle a son propre tokeniseur, et le ratio tokens/mots n’est pas le même en français, en anglais ou en chinois – un même document coûte donc un nombre de tokens différent selon le modèle et la langue. C’est une réalité technique de bas niveau, mais elle a des implications directes sur la conception des systèmes : comment on formate les documents avant de les envoyer au modèle, comment on estime les coûts à l’échelle, comment on gère les documents longs.
Contexte et context window – pourquoi la « mémoire » d’un LLM n’en est pas une ?
La context window, c’est la quantité d’information qu’un modèle peut traiter en une seule fois – l’équivalent de ce qu’il « voit » au moment de générer sa réponse. Les fenêtres de contexte ont beaucoup grandi ces deux dernières années : la plupart des modèles de premier plan proposent aujourd’hui entre 200 000 et 1 million de tokens selon l’offre, et certains vont au-delà. En pratique, une fenêtre de 200 000 tokens représente déjà plusieurs centaines de pages de texte.
Ce que ça n’est pas : une mémoire persistante. Une fois la conversation terminée, le modèle ne se souvient de rien. La prochaine session repart de zéro, sauf si vous réinjectez explicitement le contexte pertinent.
Et une fenêtre plus grande n’est pas gratuite ni sans limite pratique : au-delà d’un certain volume, la précision du modèle sur les informations situées au milieu du contexte se dégrade – un phénomène qu’on appelle parfois le « context rot ». Envoyer tout ce qui est disponible n’est donc pas une stratégie ; envoyer ce qui est pertinent en est une. C’est un argument technique de plus en faveur du RAG, même quand la fenêtre de contexte serait, en théorie, assez large pour tout contenir.
C’est un point que les utilisateurs non techniques découvrent souvent douloureusement : « mais je lui avais déjà expliqué notre contexte la semaine dernière. » Non – vous l’aviez expliqué à une instance de session qui n’existe plus. La gestion du contexte entre sessions est un problème d’ingénierie, pas une limitation qu’on subit passivement. C’est précisément ce que la mémoire agentique est conçue à résoudre.
Embedding – ce qui permet à une machine de « comprendre » le sens
Un embedding, c’est la représentation d’un texte sous forme de vecteur numérique – une liste de coordonnées dans un espace mathématique à très haute dimension. Deux textes sémantiquement proches auront des vecteurs proches. « Contrat de prestation » et « accord de service » seront représentés par des vecteurs voisins, même s’ils ne partagent aucun mot.
C’est la technologie sous-jacente au RAG : quand vous posez une question, elle est convertie en vecteur, et le système recherche les passages de vos documents dont les vecteurs sont les plus proches. C’est ce qui permet une recherche par sens plutôt que par mot-clé exact.
La qualité du modèle d’embedding utilisé influence directement la pertinence des résultats de recherche – et donc la qualité finale des réponses. C’est une variable qu’on optimise systématiquement sur les projets documentaires complexes, au même titre que le choix du LLM de génération.
Prompt et prompt engineering – plus que de la rédaction
Un prompt, c’est l’instruction envoyée au modèle. Ce que vous tapez dans une interface de chat en est un. Ce que votre application métier envoie automatiquement au LLM en arrière-plan en est un aussi, souvent bien plus long et structuré que ce que l’utilisateur voit.
Le prompt engineering, c’est la discipline qui consiste à concevoir ces instructions pour obtenir des réponses fiables, reproductibles et adaptées au contexte. Ce n’est pas de la magie, c’est de l’architecture : on définit le rôle du modèle, les contraintes de format, les exemples attendus, les cas limites à éviter.
En production, un prompt mal conçu est une source de variabilité. Deux formulations légèrement différentes peuvent produire des résultats radicalement différents sur le même modèle. C’est pourquoi le prompt engineering n’est pas une tâche qu’on délègue à l’utilisateur final – c’est une compétence d’ingénierie à part entière, intégrée dès la conception du système.
Function calling (tool use) – comment un LLM déclenche une action réelle ?
Le function calling – ou tool use – est le mécanisme technique qui permet à un LLM de ne pas se contenter de générer du texte, mais de produire une demande d’exécution structurée : « appelle telle fonction, avec tels paramètres. » Le modèle ne consulte pas votre CRM lui-même – il génère une instruction que votre application interprète et exécute, avant de lui renvoyer le résultat pour qu’il poursuive son raisonnement.
C’est la brique élémentaire sur laquelle repose tout agent : sans function calling, un LLM ne peut que parler. Avec, il peut interroger une base de données, envoyer un e-mail, déclencher un paiement – dans les limites strictement définies par les fonctions qu’on lui expose. Le corollaire est direct : un agent ne peut faire que ce que la liste de ses outils autorise. Concevoir cette liste avec précision – ni trop large, ni trop restrictive – est un exercice de conception à part entière, pas un détail d’implémentation.
Raisonnement enchaîné et modèles « thinking » – quand le modèle réfléchit avant de répondre
Certains modèles récents génèrent une séquence de raisonnement intermédiaire – parfois visible, parfois masquée – avant de produire leur réponse finale. Cette technique, souvent désignée par chain-of-thought ou « extended thinking », améliore sensiblement la fiabilité sur les tâches qui demandent plusieurs étapes logiques : un calcul, une analyse juridique à plusieurs conditions, un diagnostic technique.
Ce que ça change en pratique : ces modèles sont plus lents et plus coûteux par requête, parce qu’ils génèrent davantage de tokens avant la réponse visible. Le bon réflexe n’est pas de les activer partout – c’est de les réserver aux étapes d’un workflow qui en ont réellement besoin, et de garder un modèle plus rapide et moins cher pour les tâches simples et répétitives. Un système bien conçu mélange les deux plutôt que de choisir un seul modèle pour tout faire.
Small Language Model (SLM) – l’inverse du réflexe « toujours plus grand »
Un SLM est un modèle de langage volontairement plus petit qu’un LLM généraliste – quelques milliards de paramètres au lieu de plusieurs centaines. Il est moins polyvalent, mais plus rapide, moins coûteux à faire tourner, et parfois déployable directement sur un poste de travail ou un serveur local sans dépendre d’une API externe.
Son intérêt n’est pas de remplacer un LLM généraliste, mais de traiter les tâches étroites et répétitives d’un système agentique – classification, extraction de champs, routage d’une requête vers le bon agent spécialisé – sans mobiliser un modèle surdimensionné pour ça. Un système agentique mature combine souvent plusieurs tailles de modèles : un grand modèle pour le raisonnement complexe, des petits modèles pour les étapes mécaniques. C’est un arbitrage de coût et de latence, pas une question de principe.
Hallucination – pourquoi ça arrive, comment on le contrôle ?
Un LLM hallucine quand il produit une information fausse avec une apparente confiance. Ce n’est pas un bug corrigeable par une mise à jour – c’est une conséquence directe de son fonctionnement : le modèle génère la suite la plus probable, pas la suite la plus vraie.
Sur des tâches génériques, le taux d’hallucination est gérable. Sur des tâches métier critiques – rédaction d’un avis juridique, synthèse d’un dossier médical, réponse à un appel d’offres – il est rédhibitoire si on ne met rien en face.
La réponse opérationnelle, c’est le RAG : on ancre le modèle sur vos documents réels, et on lui demande de sourcer chaque affirmation. Un agent bien conçu ne répond pas de mémoire – il répond en citant le passage exact du document qui fonde sa réponse. Ce n’est pas une garantie absolue, mais c’est ce qui permet de déployer de l’IA sur des processus où l’erreur a un coût réel.
Fine-tuning – quand c’est utile, quand c’est un investissement inutile
Le fine-tuning consiste à réentraîner un modèle existant sur vos données spécifiques pour l’adapter à votre domaine, votre vocabulaire, votre style. C’est une opération coûteuse en temps, en données et en infrastructure.
Quand c’est pertinent : vous avez un volume massif de données labellisées, une tâche très spécifique et répétitive, et un besoin de performance sur un périmètre étroit et stable – classification de tickets, détection d’anomalies sur des flux normalisés, génération de textes dans un format très contraint.
Quand ce n’est pas la bonne réponse : vous voulez que le modèle « connaisse » vos documents internes. Le fine-tuning n’est pas fait pour ça – il apprend des patterns, pas des faits. Injecter vos contrats dans un fine-tuning ne produira pas un modèle qui cite vos contrats. Il produira un modèle qui écrit comme vos contrats. Pour la connaissance documentaire, c’est le RAG qu’il faut, pas le fine-tuning. C’est l’une des confusions les plus courantes qu’on corrige en phase de cadrage.
Les agents et l’orchestration
Agent IA – ce qui distingue un agent d’un chatbot
Un chatbot répond. Un agent agit.
Plus précisément : un agent IA est un système capable de percevoir un contexte, de raisonner sur les étapes nécessaires pour atteindre un objectif, d’utiliser des outils externes – APIs, bases de données, applications métier, via du function calling – et d’enchaîner des actions de manière autonome jusqu’à complétion de la tâche.
Un chatbot de service client répond à une question sur votre commande. Un agent de service client consulte votre historique dans le CRM, vérifie le statut de livraison dans le TMS, rédige la réponse, la soumet à validation si le remboursement dépasse un seuil, et met à jour le ticket – sans intervention humaine sur chaque étape.
La différence n’est pas cosmétique. Elle change la nature de ce qu’on peut automatiser, et donc la nature du travail humain qui reste : supervision, validation des cas limites, amélioration continue du système.
MCP – le standard qui change la donne sur les intégrations
MCP signifie Model Context Protocol. C’est un standard ouvert, proposé par Anthropic et rapidement adopté par l’écosystème, qui définit une façon commune pour un LLM de se connecter à des outils et des sources de données externes.
Avant MCP, chaque intégration était une plomberie sur mesure : connecter un agent à votre CRM, votre ERP, votre base documentaire nécessitait du développement spécifique pour chaque outil, chaque modèle, chaque cas d’usage. MCP standardise cette interface – un outil compatible MCP peut être branché à n’importe quel modèle compatible, sans réécriture.
Ce que ça change concrètement : le temps de développement des intégrations chute significativement. L’écosystème d’outils compatibles continue de grandir – la plupart des éditeurs majeurs publient désormais leurs connecteurs MCP. Et surtout, les architectures agentiques deviennent moins fragiles : moins de code de glue, moins de points de rupture, plus de standardisation. C’est un changement d’infrastructure discret mais structurant, du même ordre que l’adoption des APIs REST il y a quinze ans.
Workflow agentique – quand les agents travaillent ensemble
Un workflow agentique, c’est une chaîne de traitement où plusieurs agents spécialisés se passent la main de façon coordonnée. Chaque agent a un rôle défini – un agent recherche l’information, un agent la synthétise, un agent vérifie la conformité, un agent rédige le livrable final.
L’intérêt : la spécialisation améliore la fiabilité. Un agent conçu pour une tâche précise est plus performant et plus auditable qu’un agent généraliste à qui on demande tout faire.
Le risque : la complexité de coordination. Quand un agent échoue au milieu d’un workflow, que se passe-t-il ? Est-ce que le système détecte l’erreur, la remonte, relance l’étape ? Est-ce que l’agent suivant reçoit une entrée dégradée sans le savoir ? La robustesse d’un workflow agentique se mesure à sa gestion des cas d’échec – pas à sa performance sur le chemin nominal. C’est souvent là que les architectures trop légères montrent leurs limites en production.
Mémoire agentique – ce que l’agent retient vraiment entre deux sessions
Un agent sans mémoire persistante repart de zéro à chaque session. C’est acceptable pour des tâches ponctuelles. C’est un problème pour tout ce qui nécessite une continuité – un agent commercial qui doit connaître l’historique d’un compte, un agent de support qui suit un dossier sur plusieurs semaines.
La mémoire agentique désigne les mécanismes qui permettent à un agent de conserver et de réutiliser des informations entre les sessions. Elle se décline en plusieurs niveaux : la mémoire de travail – ce qui est dans la context window pendant la session en cours ; la mémoire épisodique – un historique des interactions passées stocké et récupérable ; la mémoire sémantique – des faits structurés sur l’entité suivie, mis à jour au fil du temps.
Concevoir la mémoire d’un agent, c’est décider quoi garder, sous quelle forme, pendant combien de temps, et avec quels droits d’accès. C’est une dimension souvent sous-estimée en phase de conception, et qui revient comme problème majeur six mois après le déploiement – d’autant plus qu’elle croise directement les obligations RGPD dès qu’elle porte sur des données personnelles (voir plus bas).
RAG – pourquoi le « copier-coller de documents » ne suffit pas
RAG signifie Retrieval Augmented Generation. Le principe : plutôt que de demander au modèle de répondre de mémoire, on lui fournit en temps réel les passages pertinents de vos documents avant qu’il génère sa réponse. Il répond sur la base de ce qu’on lui a injecté, pas de ce qu’il a appris à l’entraînement.
C’est la bonne architecture pour ancrer un LLM sur votre base de connaissance interne. Mais « RAG » recouvre des réalités très différentes en termes de qualité.
Le RAG basique – découper les documents en morceaux (chunk), vectoriser, chercher par similarité – fonctionne bien sur des textes propres et homogènes. Il échoue sur les documents réels de l’entreprise : tableaux imbriqués, mises en page complexes, documents scannés, schémas techniques. Un modèle qui ne comprend pas la structure d’un document ne peut pas en extraire l’information pertinente, quelle que soit la qualité de sa recherche.
Le RAG industriel intègre une compréhension visuelle et logique des documents, une recherche hybride qui combine similarité sémantique et correspondance lexicale, et un reranking qui garantit que ce qui arrive au modèle est réellement pertinent. C’est cet écart qui explique pourquoi des projets RAG prometteurs en démo deviennent décevants en conditions réelles.
RAG agentique – quand la recherche documentaire devient itérative
Le RAG classique fait une recherche, une fois, puis génère la réponse. Le RAG agentique confie cette recherche à un agent capable de raisonner sur ce qu’il trouve : si la première recherche est insuffisante, il reformule la requête et recherche à nouveau ; s’il repère une contradiction entre deux documents, il va chercher une troisième source pour trancher ; si la question suppose plusieurs sous-questions, il les traite l’une après l’autre avant de synthétiser.
L’intérêt est direct sur les questions complexes ou ambiguës, là où une recherche unique par similarité ne suffit pas. Le coût est tout aussi direct : plusieurs appels au modèle et à la base documentaire au lieu d’un seul, donc plus de latence et plus de dépense par requête. Le RAG agentique n’est pas une amélioration à activer partout – c’est un choix d’architecture pour les cas d’usage où la qualité de la réponse justifie ce surcoût.
Orchestration – le chef d’orchestre qu’on oublie toujours de mentionner
L’orchestration, c’est la couche qui coordonne l’ensemble : elle décide quel agent appeler, dans quel ordre, avec quelles données, et que faire en cas d’échec. Elle gère les dépendances entre tâches, les boucles de raisonnement, les appels aux outils externes.
Des frameworks comme LangChain, LlamaIndex ou LangGraph sont des outils d’orchestration. Ils permettent de câbler ensemble des LLM, des outils, des mémoires et des flux de données en quelque chose de cohérent.
Ce qu’on observe en pratique : l’orchestration est la partie la moins sexy et la plus critique d’un système agentique. Les démos montrent les agents. Les projets échouent sur l’orchestration – des workflows qui ne gèrent pas les erreurs, des agents qui se bloquent mutuellement, des contextes mal transmis d’une étape à l’autre. Investir sérieusement dans l’orchestration dès la conception, c’est la décision qui sépare les systèmes qui tiennent de ceux qu’on refait six mois plus tard.
Garde-fous (guardrails) – la différence entre un agent autonome et un agent incontrôlable
Les garde-fous sont l’ensemble des contraintes techniques posées autour d’un agent pour limiter ce qu’il peut faire, indépendamment de ce que le modèle « déciderait » de faire seul. Concrètement, ça recouvre plusieurs couches : le filtrage des entrées (détecter une tentative de manipulation dans une requête), la validation des sorties (vérifier qu’une réponse respecte un format ou ne contient pas d’information interdite avant de l’envoyer), et la limitation stricte des permissions de chaque outil exposé à l’agent – un agent de facturation qui ne peut techniquement pas dépasser un certain montant, quelle que soit l’instruction qu’il reçoit.
Le point à retenir : les garde-fous ne se négocient pas au niveau du prompt. Demander poliment au modèle de « ne jamais faire X » dans ses instructions est une aide, pas une garantie – un modèle peut être manipulé pour ignorer ses instructions. Les vraies limites sont celles qui sont appliquées en dehors du modèle, dans le code qui l’entoure : ce que l’outil autorise techniquement, pas ce que le prompt lui demande poliment.
Évaluation (evals) – comment savoir si un agent fonctionne vraiment
Une évaluation, ou eval, est un jeu de tests structuré qui mesure la performance d’un agent ou d’un LLM sur des cas représentatifs de son usage réel – pas sur des benchmarks génériques publiés par les éditeurs de modèles, qui ne disent rien de votre cas d’usage précis.
C’est ce qui permet de répondre à des questions concrètes avant et après mise en production : ce nouveau prompt améliore-t-il vraiment la qualité des réponses, ou seulement sur les trois exemples qu’on a testés à la main ? Le changement de modèle sous-jacent dégrade-t-il une capacité qu’on utilisait sans le savoir ? Sans jeu d’évaluation propre à votre système, chaque modification devient un pari – c’est pourtant l’étape que la plupart des projets sautent, faute de temps, avant de la regretter au premier incident en production.
Human-in-the-loop – quand garder l’humain dans la boucle n’est pas un aveu d’échec
Human-in-the-loop désigne les points d’un workflow agentique où une intervention humaine est explicitement requise avant de continuer – validation d’une décision, vérification d’un livrable, autorisation d’une action irréversible.
C’est souvent présenté comme une limitation temporaire, en attendant que les agents soient « assez fiables ». C’est une erreur de cadrage. Sur les processus critiques, le human-in-the-loop n’est pas un filet de sécurité provisoire – c’est une exigence de gouvernance permanente. Un agent qui envoie automatiquement des offres commerciales à des clients sans validation humaine sur les cas limites n’est pas plus mature qu’un agent qui demande une confirmation : il est juste plus risqué.
La vraie question n’est pas « comment supprimer le human-in-the-loop ? » mais « où le placer pour qu’il soit utile sans devenir un goulot d’étranglement ? » Un bon design agentique réduit la fréquence des interventions humaines en traitant automatiquement les cas standard – et les concentre sur les décisions qui méritent vraiment un jugement.
Sécurité, conformité et gouvernance
Prompt injection – le risque de sécurité propre aux agents
La prompt injection consiste à glisser une instruction malveillante dans un contenu que l’agent va lire – un document, un e-mail, une page web, un commentaire – dans l’espoir qu’il l’exécute comme s’il s’agissait d’une instruction légitime de l’utilisateur ou du système. Un agent qui résume des e-mails entrants et qui a aussi accès à votre messagerie est, par construction, exposé à ce risque : un e-mail piégé peut tenter de lui faire exfiltrer des données ou déclencher une action non voulue.
C’est un risque propre aux systèmes agentiques, pas aux chatbots classiques, précisément parce que l’agent peut agir et pas seulement répondre. La parade n’est pas un filtre unique mais une combinaison : des garde-fous techniques sur ce que chaque outil autorise, du sandboxing sur l’environnement d’exécution, et une vigilance particulière sur tout contenu externe non fiable qui entre dans le contexte de l’agent. Traiter ce risque comme secondaire parce que « c’est juste un agent de lecture » est l’erreur qu’on retrouve le plus souvent en post-mortem d’incident.
Shadow AI – l’usage que personne n’a validé
Le shadow AI désigne l’utilisation d’outils d’IA par les collaborateurs d’une organisation en dehors de tout cadre validé par la DSI ou la direction – un commercial qui colle un contrat client dans un assistant grand public pour le résumer, un développeur qui envoie du code propriétaire à un outil externe pour du debug.
Le risque n’est pas l’usage de l’IA en soi, c’est l’absence de visibilité et de contrôle sur ce qui sort de l’organisation : quelles données partent, vers quel service, sous quelles conditions de traitement. Sur ce point, la réglementation européenne récente est explicite – elle ne distingue pas les outils officiellement déployés des usages informels, et le shadow AI ne bénéficie d’aucune tolérance particulière du seul fait qu’il n’est pas piloté par l’IT. La réponse efficace n’est presque jamais l’interdiction pure, qui pousse l’usage plus loin dans l’ombre – c’est de proposer une alternative validée, aussi simple d’accès que l’outil grand public qu’on cherche à remplacer.
RGPD et IA – deux textes qui s’appliquent en même temps
Le RGPD encadre le traitement des données personnelles ; il s’applique dès qu’un système d’IA – chatbot, agent, RAG – traite des données identifiant une personne, indépendamment de toute réglementation spécifique à l’IA. Les obligations habituelles restent : base légale du traitement, information des personnes concernées, droits d’accès et de rectification, minimisation des données, durée de conservation définie.
Ce que l’IA générative complique concrètement : une mémoire agentique qui conserve l’historique d’un client pose une question de durée de conservation et de droit à l’effacement ; un document contenant des données personnelles injecté dans un RAG doit être traité avec les mêmes garanties que n’importe quel traitement de données personnelles ; et un modèle propriétaire appelé via une API hébergée hors de l’Union européenne soulève la question du transfert de données hors UE, qui a ses propres exigences. Le RGPD ne disparaît pas parce qu’un LLM est dans la boucle – il s’applique en plus des règles spécifiques à l’IA, pas à leur place.
AI Act – ce qui s’applique déjà, ce qui a été repoussé
L’AI Act est le règlement européen qui encadre le développement, la mise sur le marché et l’utilisation des systèmes d’IA au sein de l’Union européenne. Il s’applique aussi aux organisations situées hors UE dès lors que leurs systèmes d’IA sont utilisés par des personnes dans l’UE. Le texte classe les usages en quatre niveaux de risque – inacceptable (interdit), élevé, limité, minimal – avec des obligations proportionnées à chaque niveau.
Le calendrier, révisé courant 2026 par le paquet dit « Digital Omnibus », est plus étalé que prévu initialement : les pratiques interdites (comme le scoring social) sont en vigueur depuis février 2025 ; les obligations pour les fournisseurs de modèles à usage général sont en vigueur depuis août 2025 ; les obligations de transparence pour les usages à risque limité, comme le fait de signaler qu’on échange avec un système d’IA, s’appliquent depuis août 2026 ; et l’essentiel des obligations pour les systèmes à haut risque (recrutement, crédit, santé) a été reporté à décembre 2027, voire août 2028 pour certains systèmes intégrés à des produits déjà régulés. Ces reports ne dispensent pas de s’y préparer : cartographier dès maintenant quels systèmes IA de l’organisation entrent dans quelle catégorie de risque reste la bonne trajectoire, plutôt que d’attendre l’échéance.
Gouvernance IA – ce que ça recouvre concrètement
La gouvernance IA est un terme-valise. Tout le monde en parle, peu de gens le définissent opérationnellement.
Concrètement, une gouvernance IA sérieuse recouvre quatre dimensions : les accès – qui peut interroger quel agent avec quelles données, géré par rôle et non par individu ; la traçabilité – chaque interaction entre un agent et une donnée est loggée, auditable, récupérable en cas de litige ou d’audit réglementaire ; la gestion des incidents – comment on détecte qu’un agent dérive, comment on le retire de production, comment on corrige ; la mise à jour des modèles – quand un modèle sous-jacent change, comment on valide que les comportements restent conformes.
Ce cadre recoupe directement les obligations du RGPD et, pour les usages à risque, de l’AI Act – mais il ne s’y limite pas : une bonne gouvernance IA existe même pour les usages qui ne sont formellement couverts par aucun des deux textes, parce qu’elle est la condition pour que la direction puisse réellement piloter ce qui se passe, et pas seulement faire confiance en espérant que ça tienne.
Souveraineté et infrastructure
Souveraineté numérique – de quoi on parle exactement ?
La souveraineté numérique, appliquée à l’IA, désigne la capacité d’une organisation à garder le contrôle sur ses données et ses traitements – savoir où elles sont hébergées, sous quelle juridiction, avec quelles garanties contre un accès non autorisé, y compris par une autorité étrangère. Ce n’est pas un absolu binaire : c’est un curseur, qui va de l’appel à une API généraliste hébergée à l’étranger jusqu’à l’hébergement complet sur une infrastructure française certifiée, avec toute une gamme d’options intermédiaires entre les deux. Le reste de cette section décrit ces options et les critères pour choisir entre elles.
Cloud Act – le texte qu’on invoque sans le citer
Le Cloud Act est une loi fédérale américaine de 2018 qui autorise les autorités américaines à demander l’accès à des données hébergées par une entreprise soumise au droit américain – y compris quand ces données sont stockées physiquement en dehors des États-Unis, par exemple dans un datacenter européen d’un fournisseur cloud américain. C’est ce texte, précisément, que les clauses de localisation des données en Europe ne suffisent pas toujours à neutraliser : la question n’est pas seulement où sont les serveurs, mais de quelle juridiction relève l’entreprise qui les exploite.
C’est la raison pour laquelle un hébergement « en Europe » chez un acteur américain n’offre pas la même protection juridique qu’un hébergement chez un acteur de droit européen, sans lien capitalistique avec une entité soumise au droit américain. Cette distinction est au cœur des arbitrages décrits ci-dessous.
On-premise vs cloud privé – les vrais arbitrages
On-premise : le modèle tourne sur vos serveurs, dans votre infrastructure, sous votre contrôle total. Aucune donnée ne sort de votre périmètre. C’est la seule configuration qui tient juridiquement face au Cloud Act américain pour vos données les plus critiques – brevets, contrats, dossiers réglementaires.
Cloud privé : des solutions comme Amazon Bedrock déployé en VPC isolé, ou IONOS AI Model Hub hébergé en datacenter européen, offrent un intermédiaire sérieux. Vous accédez à des modèles puissants sans que vos données transitent par des infrastructures mutualisées. Les requêtes ne servent pas à réentraîner les modèles. C’est une puissance de niveau hyperscaler avec un périmètre de contrôle qui s’approche de l’on-premise – adapté aux données métier sensibles qui n’exigent pas une isolation absolue.
Le bon arbitrage n’est pas idéologique. Il dépend du niveau de sensibilité de la donnée impliquée. Traiter toutes vos données de la même façon, c’est soit dépenser trop, soit vous exposer inutilement.
Open source vs propriétaire – ni religion, ni naïveté
Les modèles open source – Llama, Mistral, Falcon, DeepSeek – publient leurs poids. Vous pouvez les télécharger, les déployer, les modifier. Aucune dépendance à un éditeur, aucune donnée envoyée à l’extérieur, coûts maîtrisés à l’échelle.
Les modèles propriétaires – GPT, Claude, Gemini – restent souvent en avance sur les benchmarks de raisonnement complexe généraliste. Ils sont accessibles via API, sans infrastructure à gérer.
Notre position : le choix n’est pas entre « open source souverain » et « propriétaire performant ». C’est un arbitrage par cas d’usage. Pour un agent de traitement documentaire métier déployé on-premise, un modèle open source bien configuré avec une architecture RAG solide surpasse souvent un modèle propriétaire appelé via API sur une tâche générique – et sans aucun des risques associés. Ce qui compte, c’est l’adéquation au besoin, pas l’appartenance à un camp.
SecNumCloud – ce que la certification garantit vraiment
SecNumCloud est le référentiel de sécurité de l’ANSSI – l’Agence nationale de la sécurité des systèmes d’information – pour les prestataires de cloud. Une infrastructure certifiée SecNumCloud offre une garantie juridique contre les lois extraterritoriales étrangères, Cloud Act américain inclus. C’est le bouclier le plus solide disponible en France pour les données sensibles hébergées hors de votre propre infrastructure.
Ce que la certification garantit concrètement : l’hébergeur est de droit français ou européen, sans lien capitalistique avec une entité soumise à une juridiction extraterritoriale ; les données restent sur le territoire national ; les procédures de sécurité sont auditées et certifiées par l’ANSSI.
Pour qui c’est pertinent : les opérateurs d’importance vitale (OIV), les administrations, les entreprises traitant des données de santé ou des informations classifiées sensibles. Pour les autres, SecNumCloud est un signal fort de sérieux – mais ce n’est pas la seule option valable. Un cloud privé IONOS ou OVHcloud sans certification SecNumCloud offre déjà des garanties substantielles pour la grande majorité des cas d’usage métier.
Sandboxing – pourquoi isoler l’exécution des agents n’est pas paranoïaque
Un agent IA qui peut exécuter du code, appeler des APIs, lire et écrire des fichiers est un agent qui peut faire des dégâts s’il reçoit des instructions malveillantes – via une prompt injection, par exemple – ou s’il raisonne de façon inattendue. Le sandboxing consiste à isoler l’environnement d’exécution de l’agent : il opère dans un périmètre contrôlé, sans accès direct au système hôte, avec des permissions explicitement définies.
Concrètement : un agent de traitement documentaire n’a pas besoin d’accès réseau vers l’extérieur. Un agent d’analyse financière n’a pas besoin d’écrire dans le système de fichiers au-delà d’un répertoire dédié. Définir ces périmètres dès la conception, c’est limiter la surface d’attaque et les effets de bord d’un comportement inattendu.
C’est une mesure d’hygiène standard en sécurité logicielle – appliquée aux agents IA, elle devient critique dès lors que ces agents agissent sur des systèmes de production. Les ignorer parce que « c’est de la R&D » est l’erreur classique qu’on observe dans les projets qui reviennent en maintenance corrective six mois après le déploiement.
Ce glossaire reflète ce qu’on observe sur le terrain depuis plusieurs années de projets IA en production. Les définitions évoluent vite – les enjeux, moins.
