Tech-Connect Actualités tech, tutoriels et astuces informatiques expliqués simplement
Vous avez déjà collé un extrait de contrat, un tableau de chiffres ou une question RH dans ChatGPT ? Vous n’êtes pas seul : chaque jour, des millions de personnes confient des informations confidentielles à des outils d’intelligence artificielle sans jamais se demander où ces données finissent réellement. C’est exactement le sujet qu’a creusé Lars Bergmann, Ingénieur relations développeurs chez l’hébergeur allemand mittwald, dans un podcast d’environ 45 minutes consacré aux agents d’IA, à la souveraineté des données et à la manière dont les entreprises peuvent garder la main sur leur infrastructure. On a écouté l’épisode en entier, on a creusé les zones d’ombre, et on vous restitue ici l’essentiel en clair, avec des exemples concrets, pour que vous puissiez agir dès aujourd’hui.
| 💡 À savoir « Agent IA » : contrairement à un chatbot classique qui se contente de répondre à des questions à partir de ses connaissances générales, un agent IA peut agir de façon autonome. Il utilise des outils (lire un fichier, interroger un site, écrire dans une base de données) pour aller chercher de l’information ou déclencher des actions concrètes, sans intervention humaine à chaque étape. |
Agent IA ou simple chatbot ? La nuance qui change tout
Pendant longtemps, l’hébergement rimait avec serveurs, noms de domaine et bases de données. Ce vocabulaire a pris un coup de vieux. Aujourd’hui, les agents d’IA agissent de manière de plus en plus autonome : ils récupèrent des données, remplissent des formulaires, déclenchent des processus métier, souvent sans que l’entreprise sache exactement où ces opérations s’exécutent ni quelle infrastructure se cache derrière.
La distinction technique est pourtant simple à saisir. Un grand modèle de langage (LLM) classique dispose d’une « connaissance du monde » figée, acquise pendant son entraînement. Un agent, lui, y ajoute des outils : la capacité de rechercher sur le web, de lire et écrire des fichiers, d’interroger une base de données ou d’appeler une API externe. C’est ce passage du simple dialogue à l’action autonome qui change complètement la donne en matière de risque et qui explique pourquoi la question de l’hébergement redevient centrale.
Le vrai enjeu : où vivent vos données ?
Hyperscaler américain ou hébergeur européen : la différence n’est pas là où on l’attend
Beaucoup d’entreprises partent du principe qu’héberger son IA chez un géant américain (OpenAI, Google, Microsoft) est plus risqué qu’un fournisseur basé en Europe. Techniquement, la réponse est plus nuancée : les mêmes processus sont à l’œuvre des deux côtés. Ce qui ressemble à une réponse instantanée repose en réalité sur toute une chaîne de services : journaux d’activité (logs), sauvegardes, services intermédiaires. Vos données transitent et sont traitées, quel que soit le fournisseur.
La vraie différence se situe ailleurs : dans la volonté de transparence de chaque fournisseur d’expliciter et de divulguer la manière dont ils gèrent ces données. Certains formalisent un accord de sous-traitance des données (DPA : Data Processing Agreement) en bonne et due forme ; d’autres se contentent d’une clause perdue dans des conditions générales interminables. C’est cette disparité qu’il faut scruter avant de confier des données sensibles à un service tiers.
| ⚠️ Attention au problème du Shadow AI Le phénomène a un nom : le Shadow AI, ou informatique fantôme liée à l’intelligence artificielle. Selon une étude relayée début 2026, 61 % des utilisateurs professionnels de l’IA en France accèdent à ces outils via des comptes personnels, en dehors de tout contrôle de la DSI, au moins une fois par semaine. Au niveau mondial, 38 % des salariés admettent avoir partagé des informations professionnelles sensibles avec des outils d’IA non autorisés. Contrats, données RH, prévisions financières, bases clients : ces documents circulent parfois sans que la direction en ait la moindre idée. Ces chiffres varient selon les études et les pays, ils donnent un ordre de grandeur, pas une vérité universelle. |
Le risque n’est pas théorique. Lars Bergmann raconte avoir entendu des cas concrets dans des services RH où des décisions concernant des salariés ont été prises uniquement sur la base de recommandations générées par une IA, un scénario qui, s’il venait à être connu publiquement, déclencherait un scandale largement mérité.
Pourquoi un bon prompt ne suffit plus
On a longtemps cru que la clé d’un bon résultat avec l’IA résidait dans la formulation de la question, le fameux « prompt engineering ». Lars Bergmann a voulu vérifier cette intuition par lui-même : il a fait résoudre des milliers de fois la même tâche de programmation, en alternant prompts longs et détaillés, et instructions minimalistes du type « tu vois ce qu’il faut faire, vas-y ».
Résultat surprenant : ce n’est pas la formulation du prompt qui a le plus fait varier le taux de réussite. C’est l’écosystème d’outils mis à disposition de l’agent, et la façon dont ces outils sont coordonnés entre eux. En travaillant sur cette orchestration, il est passé d’un taux de réussite d’environ 75 % à près de 95 % sur la même tâche.
Sa conclusion, devenue une sorte de mantra dans le milieu : le prompt n’est que la partie émergée de l’iceberg. Ce qui se joue en dessous : les outils, les instructions qui les accompagnent (les « skills », ou compétences), et l’orchestration de l’ensemble, pèse bien plus lourd dans la balance.
Un exemple concret : l’outil à sens unique
Imaginez un agent chargé de gérer un stock. On lui donne un outil pour augmenter le niveau des stocks… mais on oublie de lui donner celui pour le réduire. Résultat : l’agent ne peut jamais corriger une erreur, ni vérifier que son action a bien fonctionné. Il fonce droit dans une impasse : un entrepôt virtuel qui déborde, sans qu’aucun outil ne permette de revenir en arrière. C’est l’exemple typique d’une « boucle de rétroaction » manquante : chaque outil donné à un agent devrait, dans l’idéal, être accompagné d’un moyen de vérifier ou d’annuler son effet.
Le MCP, ou la prise USB-C des agents d’IA
Impossible d’aborder les agents d’IA en 2026 sans croiser cet acronyme : MCP, pour Model Context Protocol. Développé par Anthropic et lancé fin 2024, ce protocole ouvert et open-source résout un problème bien concret : avant lui, chaque connexion entre un agent et un outil externe (base de données, calculatrice, dépôt de code) nécessitait un développement sur mesure. Autant de « connecteurs maison » à maintenir, multipliés par autant d’agents et d’outils différents.
Le MCP standardise cette distribution d’outils : un serveur MCP peut désormais être branché indifféremment sur un agent Copilot, Claude, ou tout autre assistant compatible. C’est très exactement la même logique que le connecteur USB-C, qui a mis fin à la guerre des chargeurs propriétaires : un standard unique, une interopérabilité immédiate.
| 📝 Cette standardisation a un revers. Elle facilite une adoption rapide et parfois peu réfléchie : dupliquer treize fois un outil quasi identique dans sa boîte à outils MCP ne crée aucune valeur, seulement de la confusion pour l’agent qui doit choisir entre eux. La recommandation des experts est claire : ne transposez pas mécaniquement toutes vos interfaces de programmation existantes en outils MCP. Mieux vaut une boîte à outils sobre et bien pensée qu’un fourre-tout. Des chercheurs en sécurité ont documenté, en avril 2025, des vulnérabilités du protocole liées à l’injection de prompts et à des « outils empoisonnés » capables d’exfiltrer des données via d’autres outils connectés. Ce point mérite une vigilance particulière avant tout déploiement en environnement sensible. |
RAG et modèle « Artisan » : comment nourrir l’IA sans tout lui donner
Pour obtenir de bons résultats, une IA a besoin de bonnes données, dans l’idéal, celles de l’entreprise elle-même. Mais donner un accès brut aux bases de données internes n’est pas la meilleure idée, loin de là. Lars Bergmann propose une distinction utile entre deux approches.
Le modèle « Oracle » consiste à tout déverser dans le grand modèle de langage et à espérer une réponse pertinente : « Voici mes données, cher Oracle, trouve-moi la réponse. » Cette approche maximise les risques d’hallucination, ces réponses inventées de toutes pièces mais formulées avec assurance et de fuite de données sensibles.
Le modèle « Artisan » (Craftsman Pattern) fonctionne à l’inverse : plutôt que de demander directement la réponse à l’IA, on lui demande quel outil permettrait d’y arriver ou d’en créer un par vibecoding. Concrètement, on développe un petit outil d’analyse dédié (par exemple : « quel produit se vend le mieux ce mois-ci ? »), et les données restent stockées en local, sous le contrôle de l’entreprise. L’IA ne fait qu’orchestrer l’appel à cet outil, sans jamais voir transiter la donnée brute sur le réseau.
C’est là qu’intervient le RAG (Retrieval-Augmented Generation, ou génération augmentée par récupération) : une technique qui permet à un agent d’aller chercher des informations précises dans une base de connaissances propre à l’entreprise, au moment où il en a besoin, plutôt que de tout injecter en amont dans le modèle.
Exemple concret pour débuter
Pas besoin d’une infrastructure complexe pour appliquer ce principe. Pour une analyse de données personnelle ou pour une petite entreprise, un simple fichier Excel ou CSV stocké en local, couplé à un script ou une macro développée avec l’aide d’un assistant IA, suffit largement. Le calcul se fait en local, aucune donnée ne transite vers l’extérieur, et la facture en tokens (l’unité de consommation facturée par les fournisseurs d’IA) reste minime, l’analyse statistique de gros volumes via un LLM consomme, elle, une quantité de ressources nettement plus importante pour un résultat souvent équivalent.
Garder le contrôle : pare-feu, limitation de débit et l’anecdote qui fait réfléchir
Donner à un agent l’accès à des systèmes tiers, c’est un peu comme lui confier les clés de la maison en lui souhaitant bonne chance. Sans garde-fous techniques, un agent livré à lui-même peut multiplier les appels à une API externe jusqu’à déclencher des mécanismes de protection… contre lui-même.
Lars Bergmann en a fait l’expérience à ses dépens : après avoir laissé tourner un agent pendant quelques heures, il est revenu le soir pour découvrir un message de Google signalant que son adresse IP n’était plus considérée comme fiable. L’agent avait multiplié les appels aux API de Google jusqu’à atteindre la fameuse limite de débit (rate limiting), provoquant un bannissement temporaire. Un simple garde-fou technique, une limitation du nombre de requêtes par minute, aurait suffi à éviter l’incident.
Cette anecdote illustre une règle plus générale : on ne peut pas se contenter d’instructions textuelles données à un agent (« s’il te plaît, ne mens pas », « ne dépasse pas cette limite ») pour garantir un comportement fiable. Il faut des mesures techniques réelles (pare-feu, limitation de débit, cloisonnement des accès) capables de contenir un agent qui s’emballe, y compris lorsque ce dérapage vient de sous-agents invisibles multipliant les appels sans qu’on s’en rende compte.
Par où commencer ? La feuille de route en 3 étapes
Face à cette complexité, la tentation est grande de vouloir « tout faire avec l’IA » immédiatement. Lars Bergmann recommande l’inverse : garder les pieds sur terre et avancer par étapes.
- Dresser un état des lieux. Avant d’agir, il faut cartographier l’existant : quels outils d’IA sont déjà utilisés dans l’entreprise, par qui, et pour quoi faire ? Cette étape permet de mettre au jour le Shadow AI évoqué plus haut sans esprit de flicage, mais dans une logique de compréhension collective.
- Évaluer les risques, pas les technologies. Un outil couramment cité pour cet exercice est l’AMDE (Analyse des Modes de Défaillance et de leurs Effets) : on liste ce qui pourrait mal tourner, puis on évalue l’ampleur de l’impact potentiel. Un service RH qui prend des décisions basées sur l’IA sans encadrement pèse plus lourd, en termes de risque réputationnel, qu’une équipe créative qui génère un brouillon de texte pour s’inspirer.
- Poser des règles du jeu et les partager. La dernière recommandation, et sans doute la plus importante : établir des règles claires, transparentes et accessibles à l’ensemble des collaborateurs, plutôt que de laisser chacun improviser dans son coin. Cela suppose de la pédagogie : expliquer aux équipes ce qu’implique le fait d’injecter certaines données dans un outil d’IA, sans jugement, mais avec de la rigueur.
Si l’on devait retenir une seule idée de cet échange, ce serait celle-ci : la question n’est plus seulement « quelle IA vais-je utiliser ? », mais « qu’advient-il de mes données une fois que je les lui confie ? ». Le débat sur la souveraineté numérique européenne est souvent caricaturé en opposition binaire, Europe vertueuse contre Big Tech américain tout-puissant, alors que la réalité, on l’a vu, est plus subtile : la transparence contractuelle compte parfois davantage que la simple localisation géographique des serveurs. Ce qui semble certain, en revanche, c’est qu’aucune entreprise ne peut plus se permettre d’ignorer le sujet en misant sur la chance. Reste à savoir si la régulation (RGPD, AI Act européen) parviendra à suivre le rythme d’une technologie qui, comme le dit si bien Lars Bergmann, connaît « une accélération de l’accélération de l’accélération ». Et vous, où en êtes-vous dans cette réflexion ? On a hâte de lire vos retours en commentaires.
On en débat avec vous
- Votre entreprise a-t-elle déjà formalisé des règles claires sur l’utilisation de l’IA, ou le sujet reste-t-il encore flou chez vous ?
- Faites-vous confiance à un hébergeur basé hors d’Europe pour vos données professionnelles, ou privilégiez-vous une solution souveraine ?
- Avez-vous déjà été confronté à un agent IA qui s’est « emballé » : trop de requêtes, actions inattendues ? Racontez-nous votre anecdote !
- Le modèle « Artisan » (garder ses données en local et ne confier que des outils à l’IA) vous semble-t-il réaliste pour votre activité, ou trop contraignant ?
