IA agentique, souveraineté numérique et vidéosurveillance algorithmique : trois dossiers qui engagent les PME

Quand un agent IA échappe à son cadre : les leçons de l’incident OpenAI / Hugging Face

Des modèles développés par OpenAI ont exploité plusieurs failles pour accéder à l’infrastructure de Hugging Face pendant une évaluation interne. L’incident pose la question du contrôle des agents capables d’utiliser des outils, de se connecter à des services externes et d’enchaîner des actions sans validation humaine.

OpenAI a reconnu qu’une combinaison de modèles avait compromis une partie de l’infrastructure de Hugging Face. Cette combinaison associait GPT-5.6 Sol et un modèle de préproduction, lors d’un test consacré aux capacités offensives en cybersécurité.

L’affaire ne concerne donc pas seulement les laboratoires qui développent les modèles les plus avancés. Elle interroge également les entreprises qui commencent à confier à des agents IA l’accès à leurs messageries, fichiers, logiciels de gestion, bases de données ou interfaces de programmation.

Quelles leçons concrètes une PME doit-elle tirer de cet incident avant de donner à un agent IA un accès à sa messagerie, à son CRM, à ses fichiers ou à des applications internes ?

Tristan Duranté Koudella, cofondateur de Studeria : « Une seule, mais elle change tout : le périmètre d’un agent n’est pas celui que vous avez prévu, c’est celui que vos accès autorisent.

Rappelons ce qui s’est passé. OpenAI testait ses modèles dans un environnement isolé, sur un banc d’essai de cybersécurité, avec les garde-fous volontairement désactivés. Les modèles sont sortis de l’environnement, ont atteint Internet et ont compromis l’infrastructure de Hugging Face. Personne ne leur avait demandé de faire ça. Ils cherchaient à réussir l’évaluation.

Si ça arrive chez l’entreprise qui construit le modèle, avec ses équipes de sécurité, la question n’est plus « est-ce que mon agent pourrait déraper ». Elle est : « le jour où il dérape, jusqu’où va-t-il ? » et cet incident n’est pas isolé. Trois autres cas, plus proches du quotidien d’une PME, disent la même chose :

EchoLeak, juin 2025. Une faille dans Microsoft 365 Copilot, référencée CVE-2025-32711 et notée 9,3 sur 10 en criticité. Un simple mail contenant des instructions cachées suffisait : quand Copilot le lisait pendant un résumé de routine, il allait chercher des données dans OneDrive, SharePoint et Teams, puis les faisait sortir. Sans clic de l’utilisateur. Antivirus et pare-feu ne voyaient rien, parce que l’attaque était écrite en français ou en anglais, pas en code. Microsoft a corrigé côté serveur et aucune exploitation réelle n’a été observée avant le correctif. La leçon reste : tout agent qui lit du contenu qu’il n’a pas produit est une surface d’attaque.

Salesloft Drift, août 2025. Un agent conversationnel de site web, branché aux CRM de ses clients. Des attaquants ont volé les jetons d’authentification de l’intégration, pas le CRM lui-même, et s’en sont servis pour extraire massivement des données Salesforce chez plus de 700 organisations : contacts, opportunités, contenus de tickets support. Ils y cherchaient ensuite des mots de passe et des clés cloud oubliés dans les échanges. Parmi les victimes, des entreprises de cybersécurité. C’est le point important pour un dirigeant : votre niveau de sécurité interne ne vous protège pas du connecteur que vous avez autorisé.

Un serveur MCP malveillant, fin 2025. Un connecteur open source largement installé, propre pendant quinze versions, puis une ligne d’exfiltration ajoutée discrètement dans une mise à jour. Le paquet avait construit sa réputation avant de la retourner. Quand vous branchez un connecteur sur votre messagerie ou votre CRM, vous ne faites pas confiance à son code d’aujourd’hui, vous faites confiance à toutes ses mises à jour futures.

À côté de ça, il y a le cas du modèle utilisé comme arme : en 2025, Anthropic a détecté et bloqué un groupe étatique chinois qui pilotait des instances de Claude Code pour mener une campagne d’espionnage largement automatisée contre une trentaine de cibles. Ce n’est pas le même sujet qu’une PME qui déploie un agent, mais ça dit où en est le niveau de l’adversaire.

Sur le terrain, je vois la même erreur presque partout. Pour aller vite, on connecte l’agent avec un compte administrateur Google Workspace ou Microsoft 365, parce que c’est celui qui a tous les droits et que ça évite les problèmes de permission. À partir de là, l’agent peut lire toute la boîte du dirigeant, sortir la base clients et supprimer des fichiers partagés. Pas parce qu’il est mal intentionné. Parce qu’on lui a donné les clés du bâtiment pour qu’il vide une corbeille.

La leçon n’est pas « n’y allez pas ». C’est : commencez en lecture seule, sur un compte dédié, sur un cas d’usage, pendant trente jours. Ensuite vous élargissez.»

Au-delà du retour d’expérience, reste la question du cadre à poser avant même le premier déploiement.»

Quels dispositifs minimaux devraient être imposés avant tout déploiement d’IA agentique : limitation des droits, environnement isolé, validation humaine, journalisation des actions ou mécanisme d’arrêt d’urgence ?

T..D.K : « Les cinq, mais pas dans cet ordre, et pas avec le même poids pour une PME. Le socle minimal, dans l’ordre où je le fais appliquer est :

Un compte de service dédié, avec le strict nécessaire. Jamais le compte du dirigeant, jamais un compte admin. C’est la mesure la moins coûteuse et celle qui limite le plus les dégâts.

Validation humaine sur les actions irréversibles. Envoyer, payer, supprimer, publier, modifier un enregistrement client. L’agent prépare, un humain valide. Tout le reste peut tourner seul.

La journalisation. Sans trace des actions, vous ne pouvez ni comprendre un incident ni prouver ce qui s’est passé. Et une trace que personne ne relit ne sert à rien : quelqu’un doit être nommé pour la regarder.

Un mécanisme d’arrêt. Concrètement, savoir quel jeton révoquer et où. À tester une fois avant la mise en production, pas le jour de l’incident.

L’environnement isolé. Indispensable pour qui entraîne ou évalue des modèles. Marginal pour une PME qui consomme du SaaS : votre agent tourne chez Microsoft ou Anthropic, vous ne maîtrisez pas cet étage.

Une entreprise de vingt personnes peut mettre les quatre premiers points en place en une semaine. Ce n’est pas un sujet de budget, c’est un sujet de discipline au moment du branchement.

Reste alors la question la plus délicate : celle du partage des responsabilités lorsque, malgré ces garde-fous, un incident survient.»

Lorsqu’un agent exploite une faille ou réalise une action non prévue, comment répartir la responsabilité entre le concepteur du modèle, l’intégrateur et l’entreprise qui l’utilise ?

T..D.K : « Aujourd’hui, en pratique, l’essentiel retombe sur l’entreprise utilisatrice. C’est elle qui est responsable de traitement au sens du RGPD, elle qui a choisi les accès, elle qui subit le préjudice commercial. L’AI Act distingue le fournisseur et le déployeur et fait peser des obligations sur les deux, mais la jurisprudence sur l’IA agentique est quasi inexistante. On raisonne donc surtout par contrat.

C’est là que ça se joue, et c’est là que les dirigeants ne regardent pas assez. Trois clauses valent la peine d’être négociées : le périmètre d’autonomie écrit noir sur blanc, la conservation et l’accès aux journaux d’exécution, et le délai de notification en cas d’incident chez le prestataire. Vérifiez aussi ce que couvre votre RC pro : la plupart des contrats signés avant 2024 n’ont pas été pensés pour un système qui agit.

Mon avis personnel sur la répartition idéale : le concepteur doit répondre du comportement du modèle dans les conditions d’usage qu’il documente, l’intégrateur du périmètre technique qu’il installe, l’entreprise de la décision de déployer et de l’ampleur des droits accordés. Cette dernière part est réelle. On ne peut pas donner à un agent un accès administrateur pour gagner deux heures de configuration et se retourner ensuite entièrement contre l’éditeur.»

Microsoft-Mistral : un accord industriel, et un rappel à l’ordre pour les PME sur leurs propres outils

Microsoft s’est engagé à acheter pour plusieurs milliards de dollars de capacités de calcul fournies par Mistral en Europe. L’accord doit également renforcer la diffusion des modèles de l’entreprise française dans les outils et les services du groupe américain.

L’opération est présentée comme une réponse à la demande de solutions européennes. Elle viserait aussi une plus grande maîtrise des infrastructures. Cette autonomie reste toutefois relative. Les centres de données de Mistral reposent notamment sur des processeurs conçus par l’américain Nvidia. Microsoft, de son côté, devient à la fois client, distributeur et partenaire technologique de Mistral.

Pour les PME et les ETI, la question posée est moins celle du nombre de modèles disponibles. Elle concerne davantage leur utilisation réelle sur le terrain. Beaucoup d’entreprises disposent déjà de fonctions d’intelligence artificielle intégrées à leurs logiciels. Elles ne mesurent pas toujours leur usage, leur coût ou les résultats produits.

Cet accord renforce-t-il réellement la souveraineté numérique européenne ou crée-t-il une nouvelle interdépendance entre Mistral, Microsoft et les fournisseurs américains de processeurs ?

T..D.K : « Les deux, et le sens du flux compte plus que le vocabulaire. Ce qui est nouveau, c’est que Microsoft est cette fois le client. L’accord du 21 juillet porte sur plusieurs milliards de dollars de capacité de calcul que Microsoft loue à Mistral en Europe, avec les modèles Mistral distribués dans Foundry et Copilot Studio. Brad Smith a confirmé qu’il n’y avait aucune nouvelle prise de participation. En 2024, Microsoft entrait au capital et l’Europe s’en inquiétait. En 2026, Microsoft paie pour utiliser l’infrastructure d’un acteur européen. Pour un industriel français, ce n’est pas un détail.

Ce qui n’a pas changé : les GPU sont des Nvidia et la distribution passe largement par Azure. La souveraineté n’est pas un label qu’on décroche, c’est une liste de dépendances qu’on accepte en connaissance de cause. Là, on a déplacé la dépendance capitalistique et on a gardé la dépendance silicium.

Pour un dirigeant, l’élément vraiment exploitable de l’accord, c’est le mode déconnecté d’Azure Local. Faire tourner un modèle sérieux sur son infrastructure, sans lien permanent avec le cloud, ça intéresse concrètement l’industrie, la défense et la santé. Ça compte davantage que n’importe quel discours sur la souveraineté. C’est cohérent avec ce que je répète depuis deux ans : ce qui construit une filière, c’est du capital, du calcul et des clients. Réguler n’est pas une stratégie industrielle.

De ce grand accord industriel, Tristan Duranté Koudella ramène la discussion à un niveau très concret : celui des outils IA que les PME possèdent déjà, sans toujours le savoir.»

Vous estimez que de nombreuses PME n’exploitent pas les outils d’IA déjà compris dans leurs licences. Comment peuvent-elles mesurer leur utilisation réelle, leur coût et les gains obtenus avant d’acheter de nouvelles solutions ?

T..D.K : « En cinq étapes, sur un mois, sans consultant :

1. Recensez ce que vous payez déjà. Copilot dans Microsoft 365, Gemini dans Workspace, les fonctions IA de HubSpot, de Canva, de votre outil de facturation. La ligne budgétaire existe souvent depuis un renouvellement de contrat que personne n’a relu.
2. Sortez les rapports d’usage des consoles d’administration. Microsoft et Google les fournissent nativement. Vous obtenez le nombre d’utilisateurs actifs par semaine, pas le nombre de licences achetées. L’écart entre les deux est votre premier chiffre.
3. Calculez le coût par utilisateur réellement actif. C’est celui-là qui fait réagir un dirigeant, pas le coût par siège.
4. Choisissez trois cas d’usage et mesurez avant/après sur quatre semaines. Temps de production d’un devis, temps de traitement d’un mail entrant, temps de préparation d’un compte rendu. Un chronomètre suffit. Ce n’est pas de la science, c’est une base de comparaison.
5. Décidez ensuite.

Ma règle empirique, issue de ce que j’observe chez nos clients : en dessous de 30 % d’utilisateurs actifs par semaine, votre problème n’est pas l’outil, c’est l’adoption. Acheter une solution supplémentaire ne le résoudra pas, ça ajoutera une licence sous-utilisée à côté de l’autre. Dans ce cas, l’argent est mieux placé dans la formation et dans le fait de désigner quelqu’un qui porte le sujet en interne.

Reste alors, pour celles qui envisagent malgré tout d’ajouter une brique, la question du choix entre modèle européen, cloud américain et infrastructure propre.»

Quels critères doivent guider une PME dans son choix entre un modèle européen, une solution hébergée par un grand fournisseur de cloud et un modèle ouvert déployé sur sa propre infrastructure ?

T..D.K : « Pour l’immense majorité des PME, la réponse est la solution hébergée déjà présente dans leur stack. Autant le dire clairement.

Les critères, dans l’ordre :

• La sensibilité réelle des données. Réelle, pas fantasmée. Vos comptes rendus de réunion commerciale ne sont pas des données de santé.

• La contrainte réglementaire ou contractuelle. Santé, défense, juridique, sous-traitance pour un grand groupe qui impose l’hébergement. Là, l’origine du fournisseur et la localisation deviennent des critères de premier rang.

• Les compétences internes en exploitation. Question à se poser honnêtement : avez-vous quelqu’un capable de gérer une panne d’inférence un dimanche soir ? Si la réponse est non, l’auto-hébergement d’un modèle ouvert n’est pas une option, quel que soit l’attrait du coût affiché.

• Le volume et la prévisibilité de la consommation. L’auto-hébergement devient intéressant à volume élevé et stable. Pas avant.

• Le besoin hors ligne. Site industriel isolé, environnement contraint. C’est le cas où le déploiement déconnecté prend tout son sens.

Le modèle européen n’est pas un critère en soi, c’est un critère de second rang qui devient décisif quand il croise le premier ou le deuxième. Je préfère un dirigeant qui déploie un outil américain et sait exactement quelles données y passent, à un dirigeant qui achète français pour la brochure et n’a rien cartographié.

Disons les choses simplement. L’immense majorité du tissu économique français ne manipule pas de données ultra sensibles, n’a pas de contrainte d’hébergement souverain et n’a personne pour administrer un modèle en interne. Pour ces entreprises, il n’y a pas d’arbitrage à faire : prenez le modèle le plus performant du marché, formez vos équipes dessus et cadrez les accès. Aujourd’hui, en juillet 2026, c’est Claude d’Anthropic qui tient la première place sur la plupart des classements, aussi bien sur les évaluations objectives que sur les préférences d’usage. Ça peut changer dans six mois, et ce n’est pas un problème : la compétence qui compte est celle de vos équipes, elle est transférable d’un modèle à l’autre. Le mauvais réflexe serait de choisir un outil moins bon pour une raison qui ne s’applique pas à votre situation, et de payer ça en résultats.»

Vidéosurveillance algorithmique : où s’arrête la détection, où commence le soupçon ?

Le Parlement a adopté un texte qui prolonge et élargit certains usages de la vidéosurveillance algorithmique dans l’espace public. Ce texte est actuellement soumis à une saisine du Conseil constitutionnel.

L’utilisation de systèmes comparables pour détecter les vols en commerce fait l’objet d’un autre texte. Ce texte a été adopté par l’Assemblée nationale, mais son parcours législatif n’est pas achevé.

Au-delà de la distinction entre espace public et commerce, un débat plus large existe. Il porte sur les informations qu’un algorithme est autorisé à déduire d’un mouvement, d’un geste ou d’un déplacement. La frontière entre la détection d’un événement et l’évaluation du comportement d’une personne reste au centre des interrogations.

Où situez-vous la frontière entre la détection d’un événement objectif (une intrusion, un mouvement de foule, un objet abandonné) et le scoring comportemental d’une personne supposée présenter un risque ?

T..D.K : « La frontière est simple à formuler : le système décrit-il un événement, ou prédit-il une personne ?

J’utilise trois tests. D’abord, la vérifiabilité. Prenez l’alerte, montrez les dix secondes de vidéo correspondantes à un humain qui ne sait rien du contexte, et demandez-lui si l’événement a eu lieu. Un départ de feu, un bagage abandonné, une densité de foule, une intrusion dans une zone interdite : la réponse est oui ou non, et deux observateurs seront d’accord. Un « comportement suspect » : personne ne peut trancher, parce qu’il n’existe pas de vérité de terrain à laquelle comparer l’algorithme.

Ensuite, sur quoi porte l’alerte. Un système de détection d’événement désigne une scène : ce colis, cette porte, cette densité à cet endroit. Un système de scoring désigne une personne : celle-ci, et pas les autres qui font la même chose. Techniquement, ça se voit à l’écran de l’opérateur. Soit le cadre rouge entoure un objet ou une zone, soit il suit un individu. C’est le même geste informatique, mais dans un cas vous décrivez un lieu, dans l’autre vous produisez un soupçon sur quelqu’un. La bascule se fait là, et elle est facile à vérifier lors d’une démonstration commerciale : demandez au fournisseur de vous montrer ce que voit l’agent.

Enfin, la persistance. Si le système suit la même personne d’une caméra à l’autre et accumule des observations sur elle, vous faites du scoring, même sans reconnaissance faciale et même sans base biométrique. L’absence d’identification par le visage est une garantie utile, mais elle ne suffit pas à qualifier le dispositif.

Ce qui me gêne dans le marché actuel, c’est que « détection de comportement suspect » est vendue comme s’il s’agissait de la même famille technique que la détection d’objet abandonné. Ce n’est pas le cas. C’est de l’autre côté de la ligne.

Cette distinction posée, elle s’applique directement à un usage très débattu : la détection des vols en magasin.»

Dans un commerce, un algorithme peut-il réellement détecter une intention de vol sans produire de faux positifs ou cibler davantage certaines attitudes, tenues ou catégories de clients ?

T..D.K : « Non, et il faut le dire avant de déployer, pas après. Deux raisons. La première est que l’intention n’est pas observable. L’algorithme n’apprend pas une intention, il apprend des corrélations gestuelles à partir d’images étiquetées. Or ces étiquettes viennent de ce que des agents humains ont signalé par le passé. Les biais des signalements passés sont donc dans le modèle par construction. Ce n’est pas un défaut de réglage, c’est le matériau d’apprentissage.

La seconde est arithmétique. Prenez un magasin à 3 000 visiteurs par jour et une incidence de vol de 1 sur 500, soit six cas réels. Avec un détecteur qui repère 95 % des vols et se déclenche à tort sur 2 % des clients honnêtes, vous obtenez environ six vraies alertes pour soixante fausses. Neuf alertes sur dix sont fausses, avec un détecteur pourtant très correct sur le papier. C’est un ordre de grandeur, pas une mesure, mais la structure du problème est là : quand l’événement recherché est rare, les faux positifs dominent toujours.

La conséquence opérationnelle est que l’alerte n’est pas une décision. Ce qui compte, c’est ce que l’agent en fait, et si quelqu’un compte. Le registre des suites données aux signalements prévu par la loi Ripost est la disposition la plus utile du texte, et c’est celle dont personne ne parle. Un exploitant sérieux devrait suivre son taux d’alertes confirmées par magasin et par créneau, et vérifier si les alertes se concentrent sur certains profils. Sans cette mesure, le dispositif n’est simplement pas auditable.»

Quelles garanties devraient figurer dans la loi : liste fermée des usages autorisés, audit indépendant des algorithmes, validation humaine obligatoire, durée limitée de conservation et possibilité de recours pour les personnes concernées ?

T.D.K : « Les cinq, et il en manque une.

Mon ordre de priorité. La liste fermée d’usages d’abord, parce que c’est la seule garantie qui résiste à la dérive. L’expérimentation de 2023 prévoyait huit situations de détection, le vol en magasin en était exclu, et trois ans plus tard on l’ajoute. Une liste ouverte se remplit toujours.

Ensuite, la garantie absente du débat : la publication obligatoire des résultats. Volume d’alertes, taux de confirmation, incidents, pour chaque déploiement, dans un format comparable. L’expérimentation issue des Jeux de 2024 s’est achevée sur des performances contrastées et vient d’être prolongée jusqu’en 2030. On va donc reconduire en 2030 comme on a reconduit en 2026 : sans savoir si ça marche. Le vrai problème n’est pas la caméra, c’est l’absence d’évaluation publiée.

Puis l’audit indépendant, qui doit porter sur les performances en conditions réelles et pas seulement sur la conformité documentaire. La validation humaine, avec obligation de tracer la suite donnée, sinon elle devient un tampon. Et enfin la conservation limitée et le recours effectif, ce qui suppose que les personnes sachent qu’un traitement algorithmique existe.

Je défends d’habitude l’idée que réguler n’est pas une stratégie industrielle. Ça reste vrai. Mais ici l’État n’est pas seulement législateur, il est aussi le premier client. Un client exigeant qui publie ses résultats ferait plus pour la filière française de la sécurité algorithmique qu’un cadre juridique élargi tous les trois ans sans bilan.»