Définition d’un agent IA : ce qu’il fait, et ce qui reste validé par vos équipes

Un agent IA enchaîne des étapes pour atteindre un objectif : lire, chercher, rédiger, proposer une action. Ce guide explique ce qu’il peut faire, ce qu’il ne doit pas faire seul et comment organiser la validation humaine.

Qu’est-ce qu’un agent IA ?

Un agent IA est un système qui utilise un modèle de langage pour poursuivre un objectif en plusieurs étapes. Là où un assistant conversationnel répond à une question, un agent peut consulter des informations, choisir l’étape suivante, utiliser les outils mis à sa disposition et produire un résultat : un brouillon, une fiche, un classement, une proposition d’action.

Les outils d’un agent sont ceux que vous lui ouvrez : lire une boîte de réception, rechercher dans une base documentaire, consulter une fiche client, créer un brouillon dans un logiciel. Il n’a accès à rien d’autre. Sa capacité d’action est donc une décision de conception, pas une propriété du modèle.

Le mot « agent » recouvre aujourd’hui des réalités très différentes, du simple enchaînement automatique à des systèmes qui choisissent eux-mêmes leurs étapes. Avant tout projet, la bonne question n’est pas de savoir s’il faut un agent, mais quelles étapes demandent un jugement, et lesquelles suivent une règle.

Agent IA, chatbot, automatisation : quelle différence ?

Les trois termes sont souvent confondus. Ils désignent pourtant des mécanismes distincts :

• un chatbot, ou assistant conversationnel, répond à une question dans une conversation, sans agir dans vos logiciels ;
• une automatisation exécute des étapes fixées à l’avance, toujours dans le même ordre, selon des règles explicites ;
• un agent IA combine les deux : il s’appuie sur des règles et des outils, mais une partie de son parcours dépend de l’interprétation du modèle.

Cette part d’interprétation fait sa force sur les tâches variables, et sa fragilité sur les tâches qui exigent un résultat identique à chaque fois. C’est pourquoi, dans un système bien conçu, l’agent ne porte que les étapes qui en ont besoin. Le reste est confié à des règles informatiques, plus fiables et plus simples à tester.

Que peut faire un agent IA en entreprise ?

Un agent IA est utile sur les tâches où l’information arrive sous des formes variées et doit être comprise, triée ou reformulée avant d’être traitée. Quelques exemples illustratifs :

• lire une demande reçue par email, en extraire les informations utiles et préparer la fiche correspondante dans le CRM ;
• classer les demandes entrantes par type et par urgence, puis les orienter vers la bonne personne ;
• préparer un brouillon de réponse à partir des conditions générales, des informations autorisées et des consignes de ton ;
• rassembler les pièces d’un dossier dispersées dans plusieurs outils et signaler celles qui manquent ;
• comparer une commande reçue avec le devis correspondant et relever les écarts.

Ces exemples décrivent des situations types, pas des missions réalisées. Leur point commun : l’agent prépare, une personne décide. Le gain vient du temps que la personne ne passe plus à chercher, recopier ou rédiger un premier jet, pas de la suppression de son contrôle.

Que ne doit pas faire un agent IA seul ?

Un modèle de langage produit un résultat probable, pas un résultat certain. Il peut mal comprendre une demande, se fier à une source périmée ou compléter une information manquante par une supposition plausible. Tant que ces erreurs restent dans un brouillon, elles se corrigent. Quand elles déclenchent une action, elles engagent l’entreprise.

Certaines décisions ne doivent donc pas être laissées au modèle, même lorsqu’il en est techniquement capable :

• envoyer un message à un client, un fournisseur ou un partenaire ;
• engager une dépense, valider une commande ou modifier un prix ;
• supprimer ou écraser des données ;
• prendre une décision qui affecte une personne, comme un recrutement ou une sanction ;
• modifier ses propres droits ou ceux d’un utilisateur.

Les chiffres suivent la même logique. Un prix, un délai contractuel ou une quantité en stock doivent venir du logiciel qui fait foi, par une règle informatique, et non être rédigés librement par le modèle. L’agent peut expliquer une configuration ; il ne doit pas l’inventer.

Enfin, un document lu par un agent est une donnée, pas une instruction. Un email reçu ou une page consultée ne doivent pas pouvoir modifier son comportement, étendre ses droits ou contourner une validation. Les actions sensibles sont séparées de la génération de texte et passent par des contrôles qui ne dépendent pas du modèle.

Comment organiser la validation humaine d’un agent IA ?

La validation humaine n’est pas une formalité ajoutée à la fin. Elle se conçoit en même temps que l’agent, à partir de quatre questions : qui valide, à quel moment, sur quelle information, et que se passe-t-il en cas de refus. En pratique, plusieurs règles la rendent réelle :

• l’agent produit un brouillon, jamais un envoi : le résultat arrive dans l’outil où la personne travaille déjà ;
• la personne voit les sources : elle sait sur quelles informations l’agent s’est appuyé et peut les vérifier ;
• les cas incertains sont signalés : information manquante, sources contradictoires, demande hors périmètre ;
• chaque validation est tracée : qui a validé, quand, à partir de quelle version ;
• un arrêt et une reprise manuelle sont prévus : si l’agent se comporte mal, le traitement s’arrête et le travail reprend à la main.

Dans les systèmes livrés par Pecora, les messages envoyés à l’extérieur, les dépenses, les suppressions et les décisions importantes passent par une validation humaine, sauf autorisation précise convenue avec vous. Ce périmètre peut évoluer, mais seulement après des mesures qui le justifient.

Une validation qui consiste à cliquer sur « accepter » sans rien voir n’en est pas une. Si le volume rend la relecture impossible, c’est le périmètre de l’agent qu’il faut revoir, pas la validation qu’il faut supprimer.

Quels accès donner à un agent IA ?

Un agent agit avec les droits qu’on lui accorde. Ces droits se limitent au strict nécessaire pour sa tâche : un compte dédié et identifiable, la lecture seule lorsque l’écriture n’est pas utile, la création de brouillons plutôt que l’envoi, aucun accès aux données dont il n’a pas besoin. Chaque action de l’agent doit pouvoir être retrouvée dans un journal, avec la version utilisée et les sources consultées. Le guide sur la sécurité des données détaille ces principes.

Un agent IA apprend-il de ses erreurs ?

Pas de lui-même. Dans la plupart des systèmes d’entreprise, le modèle n’est pas modifié par l’usage : il refera la même erreur tant que rien ne change autour de lui. L’amélioration vient des personnes qui exploitent le système. Elles analysent les corrections apportées aux brouillons, repèrent les causes récurrentes, puis ajustent ce qui peut l’être : une source périmée à remplacer, une consigne ambiguë à préciser, une règle à ajouter, un cas à exclure du périmètre. Chaque ajustement est ensuite vérifié sur le jeu de test, pour s’assurer qu’il corrige le problème sans en créer un autre.

Par où commencer un projet d’agent IA ?

Par une tâche précise, fréquente et vérifiable, plutôt que par un agent censé tout gérer. Un bon premier périmètre réunit quatre conditions : un volume suffisant pour que le gain compte, des informations d’entrée accessibles, un résultat qu’une personne peut contrôler rapidement, et une erreur dont le coût reste limité tant qu’elle est rattrapée avant envoi. Le premier agent sert aussi à installer les habitudes qui serviront aux suivants : validation, traces, mesure.

Comment mesurer si un agent IA fonctionne ?

Un agent se juge sur des dossiers réels comparables, pas sur une démonstration. Trois indicateurs suffisent pour commencer : la part des brouillons validés sans correction, le temps entre l’arrivée d’une demande et sa validation, et la part des cas signalés comme incertains. Ces mesures se prennent avant et après la mise en service, avec la même unité de dossier. Un quatrième indicateur compte vite : l’adoption. Un agent que personne n’utilise, ou dont les brouillons sont systématiquement réécrits, ne libère aucun temps, même si ses résultats de test sont bons. Le guide sur les hallucinations et la fiabilité détaille la méthode de test.

Pour aller plus loin

Questions fréquentes sur les agents IA

Automatisation ou IA : choisir la bonne approche pour chaque tâche

Une règle informatique donne toujours le même résultat. Un modèle d’IA interprète. Ce guide explique la différence, comment choisir tâche par tâche et pourquoi un système solide combine souvent les deux.

Quelle est la différence entre automatisation et IA ?

Une automatisation classique, dite déterministe, applique des règles écrites à l’avance : si une commande arrive avec tel statut, créer telle fiche, puis prévenir telle personne. À données identiques, le résultat est identique. On peut la tester de façon complète, expliquer chacune de ses décisions et prévoir ses erreurs, qui viennent des règles ou des données.

L’IA générative fonctionne autrement. Un modèle de langage produit la suite la plus probable à partir de ce qu’on lui fournit. Il sait lire un texte libre, résumer, reformuler, classer, extraire une information d’un email mal structuré. Mais son résultat peut varier d’une fois à l’autre, et il peut se tromper avec assurance. On dit qu’il est probabiliste.

Ni l’une ni l’autre n’est supérieure en soi. Elles ne répondent pas au même type de travail, et la plupart des processus d’une entreprise contiennent des étapes des deux natures.

Quand une automatisation suffit-elle ?

Une règle informatique est préférable dès que la tâche peut être décrite complètement, exceptions comprises. C’est le cas pour :

• récupérer une donnée dans un logiciel et la recopier dans un autre ;
• vérifier un statut, une date d’échéance ou un seuil ;
• appliquer une grille tarifaire, calculer un total, générer une facture ;
• créer un document à partir d’un modèle ;
• demander une validation, notifier une personne, archiver un fichier.

Sur ces tâches, un modèle d’IA ajouterait un coût, un délai et un risque d’erreur, sans rien apporter. C’est la règle centrale de la méthode Pecora : ne pas demander à un modèle d’IA ce qu’une règle informatique fait de manière plus fiable.

Une condition revient souvent : pour automatiser un transfert entre deux logiciels, il faut un identifiant commun, comme un numéro de client, de commande ou d’article. Sans lui, l’automatisation crée des doublons plus vite qu’une personne. Vérifier cette condition fait partie du travail avant toute automatisation.

Quand l’IA apporte-t-elle quelque chose ?

L’IA devient utile lorsque l’entrée est variable et qu’il faut la comprendre avant d’agir :

• lire des demandes reçues par email, rédigées chacune à sa façon ;
• extraire des informations de documents aux formats hétérogènes : bons de commande, devis fournisseurs, pièces justificatives ;
• résumer un long échange ou un dossier ;
• rédiger un premier brouillon à partir d’informations vérifiées ;
• retrouver une procédure en posant une question en langage courant.

Dans ces cas, écrire une règle pour chaque variante serait impossible ou trop fragile. Le modèle traite la variabilité ; le reste du système vérifie son travail et décide de la suite.

Une précaution s’impose : l’IA interprète l’entrée, elle ne tranche pas. Ce qu’elle extrait ou propose doit être vérifié par une règle ou par une personne avant d’alimenter un logiciel de référence. Une référence mal lue dans un email ne doit pas devenir une ligne erronée dans votre logiciel de gestion, puis une erreur de livraison.

Automatisation et IA générative, côte à côte

Repères généraux : chaque tâche s’évalue dans son contexte.

Comment choisir entre automatisation et IA ?

Le choix se fait tâche par tâche, pas projet par projet. Quatre questions permettent de trancher :

• La tâche peut-elle être décrite par des règles complètes, exceptions comprises ? Si oui, une automatisation.
• L’entrée est-elle un texte libre ou un document de format variable ? Si oui, l’IA peut aider à l’interpréter.
• Quel est le coût d’une erreur ? Plus il est élevé, plus les contrôles déterministes et la validation humaine doivent être présents.
• Le volume justifie-t-il l’effort ? Une tâche rare ou déjà rapide ne mérite pas toujours d’être outillée.

Il existe aussi deux réponses que l’on oublie : simplifier le processus avant de l’outiller, et ne rien automatiser. Un processus flou, sans responsable ni règles écrites, ne s’automatise pas ; il s’organise d’abord, et ce travail d’organisation se chiffre à part. Un bon audit peut aussi conclure qu’une tâche ne justifie aucun investissement : trop rare, déjà efficace ou alimentée par des données de mauvaise qualité.

Appliquées à un cas type, la saisie de commandes reçues par email dans un logiciel de gestion, ces questions donnent trois réponses différentes. Lire des emails rédigés librement et en extraire les références relève de l’IA. Vérifier que chaque référence existe et appliquer le bon tarif relève d’une règle. Accepter une commande inhabituelle, par sa quantité ou son client, relève d’une personne. Le même processus mobilise donc les trois, chacun à sa place.

Comment combiner automatisation et IA ?

Dans un système bien conçu, chaque composant fait ce qu’il fait de manière fiable. Les faits viennent des logiciels de référence, l’IA traite ce qui varie, une personne valide ce qui engage. Prenons une demande de devis reçue par email, à titre d’exemple illustratif :

• une règle détecte le nouvel email et identifie le client à partir de son adresse ;
• l’IA lit la demande et en extrait les produits, les quantités et les contraintes mentionnés ;
• une règle vérifie ces éléments dans le catalogue et applique la grille tarifaire en vigueur ;
• un modèle de document met le devis en forme ;
• l’IA rédige un court message d’accompagnement ;
• une personne relit, corrige si besoin et valide l’envoi.

Le prix n’est jamais produit par le modèle : il vient de la grille tarifaire, par une règle. Si l’IA ne reconnaît pas un produit, le dossier est signalé plutôt que complété au hasard. Cette répartition limite la part probabiliste du système aux étapes où elle est indispensable. Le système devient plus fiable, plus lisible et moins coûteux à exploiter, parce que chaque erreur a un endroit identifiable où la chercher.

Faut-il un nouvel outil pour automatiser ?

Pas nécessairement. Avant d’ajouter un outil, il faut regarder ce que permettent déjà vos logiciels : beaucoup proposent des règles, des modèles de documents et des connecteurs. L’ordre de préférence de Pecora est simple : utiliser votre environnement existant, ajouter une plateforme d’automatisation seulement si elle apporte une valeur nette, et développer une application spécifique uniquement lorsque les deux premières options sont insuffisantes. Une application sur mesure n’est pas un gage de sérieux : c’est un coût de maintenance supplémentaire, et une dépendance de plus.

Automatisation intelligente, IA intégrée : que recouvrent ces termes ?

De nombreux logiciels annoncent désormais une « automatisation intelligente » ou une « IA intégrée ». Ces termes ne disent pas ce qui se passe réellement. Pour évaluer un outil, trois questions suffisent : quelles étapes suivent des règles fixes, lesquelles passent par un modèle d’IA, et que se passe-t-il quand le modèle se trompe ou hésite. Un outil capable de répondre clairement à ces questions se contrôle. Un outil qui ne le peut pas vous demande de lui faire confiance sans moyen de vérifier.

Quelles erreurs éviter quand on automatise avec l’IA ?

Les échecs les plus courants ne viennent pas du modèle, mais de la façon dont il est employé :

• confier au modèle un calcul, un prix ou une date qu’une règle donnerait sans erreur ;
• brancher l’IA sur un processus que personne n’a décrit, en espérant qu’elle le structure ;
• oublier les exceptions, qui finissent traitées au hasard ou pas du tout ;
• juger le système sur une démonstration plutôt que sur des dossiers réels ;
• supprimer la validation humaine pour gagner du temps, avant d’avoir mesuré la fiabilité ;
• empiler les outils sans savoir lequel fait foi pour chaque information.

Comment éviter qu’une automatisation échoue en silence ?

Une automatisation qui s’arrête sans prévenir est plus dangereuse qu’une tâche manuelle : les dossiers s’accumulent sans que personne ne le voie. Chaque système doit donc prévoir une alerte en cas d’échec, la possibilité d’arrêter le traitement et une reprise manuelle documentée. Les exceptions, ces cas que la règle ne sait pas traiter, doivent arriver chez une personne identifiée plutôt que disparaître. Ces précautions valent autant pour une automatisation simple que pour un système qui intègre de l’IA.

Pour aller plus loin

Questions fréquentes

Hallucinations IA : pourquoi une IA se trompe et comment encadrer sa fiabilité

Un modèle de langage peut produire une réponse fausse, bien rédigée et convaincante. Ce guide explique d’où viennent ces erreurs, comment les mesurer avant la mise en service et comment les encadrer au quotidien.

Qu’est-ce qu’une hallucination en IA ?

On parle d’hallucination lorsqu’un modèle d’IA produit une information fausse ou inventée en la présentant comme exacte : une référence qui n’existe pas, un chiffre approximatif donné pour certain, une clause attribuée au mauvais contrat. Le terme est imagé, mais le phénomène est concret, et il concerne tous les modèles de langage actuels.

Le plus gênant n’est pas l’erreur elle-même, mais sa forme. Une réponse inventée a souvent le même ton assuré qu’une réponse exacte. Sans vérification, rien ne permet de les distinguer. C’est ce qui rend les hallucinations plus délicates à gérer que les erreurs d’un logiciel classique, qui échoue en général de façon visible.

Pourquoi une IA se trompe-t-elle ?

Un modèle de langage ne consulte pas une base de faits. Il produit, mot après mot, la suite la plus probable compte tenu de ce qu’il a appris et de ce qu’on lui fournit. Dans la plupart des cas, la suite probable est aussi la bonne. Mais pas toujours, et le modèle n’a pas de moyen fiable de savoir quand il se trompe.

Dans une entreprise, les erreurs ont en général l’une de ces causes :

• L’information manque : la réponse ne figure ni dans les sources fournies ni dans ce que le modèle a appris, et il comble le vide par une estimation plausible.
• La source est mauvaise : le document retrouvé est périmé, incomplet ou erroné. Le modèle le restitue fidèlement, erreur comprise.
• Les sources se contredisent : deux documents donnent deux valeurs, et le modèle en retient une sans le signaler.
• La recherche échoue : le bon document existe mais n’a pas été retrouvé, et le modèle répond avec ce qu’il a.
• La consigne est ambiguë : une règle formulée à l’oral, comme « au-dessus de 65 % », peut se lire avec ou sans la valeur limite.

Ces causes montrent qu’une grande partie de la fiabilité se joue hors du modèle : dans la qualité des sources, la précision des consignes et l’architecture du système. Changer de modèle règle rarement un problème de sources ou de consignes.

Hallucination ou problème de données : comment faire la différence ?

Face à une réponse fausse, le réflexe est d’accuser le modèle. Un diagnostic simple permet de corriger la bonne cause, en partant de la source citée :

• la source citée contient l’erreur : c’est un problème de données, à corriger dans le document ou dans le logiciel qui fait foi ;
• la source citée est juste mais la réponse la déforme : c’est une erreur du modèle ou de la consigne, à traiter par des contrôles ou une consigne plus précise ;
• aucune source n’est citée : soit l’information manque, soit la recherche a échoué, et le système aurait dû le signaler plutôt que répondre ;
• la source est juste mais périmée : c’est un problème de gestion documentaire, qui appelle une date de validité et un propriétaire.

Quelles erreurs surveiller selon l’usage ?

Toutes les tâches ne se trompent pas de la même façon. Un jeu de test utile cible les erreurs propres à l’usage. En extraction, on surveille les champs mal lus, les confusions de dates, d’unités ou de références. En classement, les mauvaises catégories et les urgences manquées, qui coûtent souvent plus cher qu’une erreur de catégorie. En rédaction, les affirmations non sourcées, les engagements que l’entreprise n’a pas pris et les écarts de ton. En recherche documentaire, le mauvais document ou la mauvaise version. Nommer ces erreurs à l’avance permet de les compter, et donc de savoir si le système progresse.

Comment mesurer la fiabilité d’une IA avant de l’utiliser ?

La fiabilité ne se constate pas lors d’une démonstration, elle se mesure. La méthode tient en quatre étapes :

• Constituer un jeu de test : une série de cas réels ou représentatifs, avec la réponse attendue pour chacun, y compris des cas difficiles, des cas limites et des questions sans réponse dans les sources.
• Définir les critères : exactitude des faits, présence des sources, respect des consignes, capacité à signaler une information manquante.
• Mesurer : faire passer le jeu de test, noter chaque réponse et relever les types d’erreurs, pas seulement leur nombre.
• Rejouer à chaque changement : nouveau modèle, nouvelle consigne, nouvelles sources. Une amélioration sur un point peut en dégrader un autre.

Le seuil acceptable dépend du coût d’une erreur. Pour un brouillon relu par une personne, une correction occasionnelle est tolérable. Pour une information transmise à un client sans relecture, elle ne l’est pas. C’est au dirigeant de fixer ce seuil, en connaissance de cause, avant la mise en service. Chez Pecora, ce seuil fait partie des critères de recette écrits au cadrage.

Comment réduire les hallucinations d’une IA ?

Aucune méthode ne les supprime entièrement. Plusieurs mesures, combinées, les rendent rares, visibles et sans conséquence grave :

• Fournir les sources : un système de recherche augmentée (RAG) donne au modèle les passages utiles de vos documents plutôt que de le laisser répondre de mémoire.
• Exiger les citations : chaque affirmation renvoie au document et au passage qui la justifient, pour qu’une personne puisse vérifier en quelques secondes.
• Autoriser l’absence de réponse : la consigne prévoit de répondre « information manquante » plutôt que d’estimer.
• Hiérarchiser les sources : en cas de contradiction, une règle désigne le document qui fait foi, ou signale le conflit à la personne responsable.
• Sortir les chiffres du modèle : prix, quantités, dates et totaux viennent des logiciels de référence, par des règles informatiques.
• Ajouter des contrôles automatiques : après génération, vérifier la présence des mentions obligatoires, l’absence de termes interdits et la cohérence des chiffres avec les sources.
• Réduire le périmètre : une tâche étroite, avec des consignes précises, laisse moins de place à l’improvisation qu’une demande ouverte.

Ces mesures déplacent la question. Il ne s’agit plus de savoir si le modèle peut se tromper, mais de s’assurer qu’une erreur est détectée avant de produire un effet.

Une réponse qui cite ses sources est-elle forcément juste ?

Non. Une citation peut renvoyer à un passage qui ne dit pas exactement ce que la réponse affirme : un chiffre arrondi, une condition oubliée, une exception passée sous silence. Elle peut aussi renvoyer au bon document dans une version dépassée. La citation rend la vérification rapide, elle ne la remplace pas. Un contrôle utile consiste à vérifier, sur l’échantillon de test, que chaque affirmation figure réellement dans le passage cité, et à compter les écarts comme des erreurs à part entière.

Quel rôle pour la validation humaine ?

La validation humaine est le dernier contrôle, pas le seul. Elle est indispensable pour tout ce qui engage l’entreprise : un message envoyé à l’extérieur, une dépense, une suppression, une décision qui touche une personne. Pour être efficace, elle doit être outillée : la personne voit le résultat, ses sources et les points signalés comme incertains, et peut corriger ou refuser simplement.

Une validation qui consiste à cliquer sur « accepter » sans rien voir n’est pas une validation. Si le volume rend la relecture impossible, c’est le périmètre du système qu’il faut revoir. À l’inverse, une relecture systématique de résultats toujours justes finit par être bâclée : les mesures servent aussi à placer la validation là où elle compte.

Comment suivre la fiabilité après la mise en service ?

Les documents changent, les demandes évoluent, les fournisseurs mettent à jour leurs modèles. La fiabilité mesurée au lancement ne reste pas acquise. Un suivi simple suffit souvent :

• la part des résultats validés sans correction ;
• les types de corrections apportées, pour repérer une cause récurrente ;
• la part des cas signalés comme incertains ou hors périmètre ;
• un nouveau passage du jeu de test à chaque changement important.

Chaque système doit aussi pouvoir être arrêté, avec une reprise manuelle documentée, si la qualité se dégrade. Une erreur ne doit pas disparaître silencieusement parce que le traitement a continué.

Pour aller plus loin

Questions fréquentes sur les hallucinations

Sécurité des données IA : quelles données confier, où, et à qui

Utiliser l’IA, c’est transmettre des données à des outils. Ce guide explique comment classer vos données, quelles questions poser aux fournisseurs, comment gérer les accès et ce que demande le RGPD, en termes généraux.

Quelles données peut-on confier à une IA ?

Tout dépend de la nature de la donnée et de l’outil qui la reçoit. La première étape consiste à classer vos informations. Quatre catégories suffisent pour commencer :

• Publiques : site internet, brochures, communiqués. Peu de contraintes de confidentialité, même si des questions de droits d’auteur peuvent subsister.
• Internes : procédures, consignes, informations produit non publiées. Utilisables en interne, pas nécessairement partageables avec n’importe quel fournisseur.
• Confidentielles : prix négociés, contrats, propositions commerciales, stratégie. Accès strict et usages précis.
• Personnelles : noms, coordonnées, historiques, échanges avec des clients ou des salariés. Le RGPD s’applique directement.

Pour chaque source que vous envisagez de connecter, décidez si son usage par l’IA est autorisé, pour quels usages, et qui en est propriétaire. Certaines données, comme les dossiers du personnel ou les informations de santé, sont souvent à exclure d’un premier projet, ou demandent une analyse spécifique avant tout usage.

Une précaution simple : ne pas brancher toute la documentation « pour voir ». Un catalogue des sources, même court, évite qu’un assistant donne accès à des documents que personne n’avait prévu de partager. Pour chaque source, il indique un propriétaire, une classification, les usages autorisés et une fréquence de mise à jour.

Où sont traitées les données envoyées à une IA ?

Quand vous utilisez un service d’IA, vos données peuvent passer par plusieurs endroits : le fournisseur du modèle, la plateforme d’automatisation, l’outil qui stocke l’index de recherche, les journaux techniques de chacun. Chacun est un lieu où une copie peut exister, parfois plus longtemps que prévu. Avant de choisir un outil, il faut suivre le chemin exact des données, de leur source jusqu’à la suppression.

Les questions à poser à chaque fournisseur :

• Quelles données sont transmises : textes, fichiers, réponses, représentations numériques, métadonnées ?
• Combien de temps sont-elles conservées, et dans quels journaux ?
• Servent-elles à entraîner ou à améliorer les modèles, par défaut ou sur option ?
• Où sont-elles traitées et stockées ?
• Quels sous-traitants interviennent, et êtes-vous informé en cas de changement ?
• Quelles protections existent : chiffrement, authentification forte, gestion des rôles, journaux d’accès ?
• Comment les supprimer, et que deviennent les sauvegardes ?
• Y a-t-il des transferts hors de l’Union européenne, et sur quelle base ?

Les réponses varient d’un fournisseur à l’autre, et parfois d’une fonction à l’autre chez un même fournisseur. Elles évoluent aussi dans le temps. Il n’existe pas de fournisseur sûr dans l’absolu, seulement des conditions à vérifier pour un usage donné, à consigner par écrit et à revoir régulièrement.

Qui doit avoir accès aux données dans un projet IA ?

Un outil d’IA ne doit jamais élargir les droits existants. Si une personne n’a pas accès à un dossier, l’assistant ne doit pas lui en restituer le contenu. Les droits doivent être appliqués avant que les documents ne soient transmis au modèle, et suivre les changements : départ, changement de service, document supprimé ou reclassé.

Transformer un document en représentation numérique pour un index de recherche ne le rend pas anonyme. L’index garde le niveau de confidentialité des documents d’origine, et doit suivre les mêmes règles de protection et de suppression.

Les accès des prestataires suivent la même logique :

• des comptes nominatifs, jamais partagés ;
• des droits limités au strict nécessaire pour la mission ;
• une double authentification lorsque l’outil la propose ;
• aucun mot de passe personnel demandé, notamment celui du dirigeant ;
• des accès retirés à la fin de la mission.

Chez Pecora, les outils de production sont souscrits au nom du client et payés directement par lui : il en garde la maîtrise, y compris le jour où la mission s’arrête.

Que dit le RGPD sur l’utilisation de l’IA ?

Le RGPD ne traite pas l’IA comme un sujet à part : il s’applique dès qu’un traitement porte sur des données personnelles, avec ou sans IA. Plusieurs de ses principes pèsent directement sur un projet d’IA :

• une finalité définie : on sait pourquoi les données sont utilisées, et on ne les réutilise pas pour autre chose sans base juridique ;
• la minimisation : on ne transmet que les données nécessaires à cette finalité ;
• une durée de conservation définie, y compris pour les copies, les index et les journaux ;
• la protection des données dès la conception et par défaut ;
• un contrat encadrant chaque sous-traitant, ainsi que les éventuels transferts hors de l’Union européenne ;
• une analyse d’impact lorsque le traitement présente un risque élevé pour les personnes.

Dans la plupart des projets, l’entreprise qui décide de l’usage des données est responsable du traitement ; le prestataire qui les traite pour son compte est généralement sous-traitant, ce qui doit être vérifié au cas par cas. Le règlement européen sur l’intelligence artificielle ajoute, selon les usages, des obligations propres. La CNIL publie des recommandations utiles sur ces sujets.

Un prestataire peut documenter les flux, les outils et les mesures techniques. Il ne remplace ni votre délégué à la protection des données, ni votre conseil juridique, qui gardent leur rôle. Ce guide donne des repères généraux, pas un avis juridique.

Faut-il anonymiser les données avant de les confier à une IA ?

Quand c’est possible, retirer les données personnelles qui ne servent pas à la tâche est une bonne pratique : un résumé de réclamation n’a pas besoin du numéro de téléphone du client. Il faut cependant distinguer deux opérations. Remplacer un nom par un identifiant, c’est pseudonymiser : la personne reste identifiable par recoupement, et la donnée reste une donnée personnelle au sens du RGPD. Anonymiser, c’est rendre l’identification impossible, ce qui est beaucoup plus difficile à obtenir, en particulier sur des textes libres. Dans les deux cas, la réduction des données transmises limite les conséquences d’un incident.

Quelles bonnes pratiques adopter dès le premier projet IA ?

La plupart des risques se réduisent par des décisions simples, prises avant de connecter quoi que ce soit :

• commencer par un périmètre limité, avec des données internes peu sensibles ;
• tenir un catalogue des sources : propriétaire, classification, usage autorisé, date de mise à jour ;
• vérifier les conditions de chaque fournisseur avant de lui transmettre quoi que ce soit, et les consigner ;
• souscrire les outils au nom de l’entreprise, pas au nom d’un salarié ou d’un prestataire ;
• filtrer les droits avant l’envoi au modèle, et répercuter les suppressions sur les index ;
• tracer sans tout conserver : garder qui a lancé quoi, avec quelles sources et qui a validé, plutôt que des contenus sensibles en clair dans les journaux ;
• prévoir l’incident : qui est prévenu, comment le traitement est arrêté, comment les traces sont préservées ;
• former les équipes aux usages autorisés, en particulier face aux outils d’IA grand public utilisés à titre personnel.

Que faire en cas d’incident de données avec une IA ?

Un incident peut prendre plusieurs formes : un document transmis à un outil non prévu, un assistant qui restitue une information à la mauvaise personne, un accès resté ouvert après une mission. La réaction se prépare avant : arrêter le traitement concerné si nécessaire, préserver les traces, prévenir sans attendre la personne responsable, puis communiquer les faits connus et les mesures prises. Selon la nature de l’incident, des obligations de notification peuvent s’appliquer ; votre délégué à la protection des données ou votre conseil juridique les évalue.

Comment Pecora traite-t-elle vos données ?

Avant toute mission, Pecora vous présente les outils utilisés, les données qui leur sont transmises et leurs conditions d’hébergement. Vos données restent dans vos comptes. Les copies de travail sont restituées puis supprimées sous 30 jours après la fin de la prestation. En cas de problème sérieux, le traitement concerné est arrêté, les traces sont préservées et votre référent est prévenu sans attendre la résolution. Nous ne promettons pas un hébergement systématique en France : le choix dépend de vos contraintes.

Pour aller plus loin

Questions fréquentes sur la sécurité des données