Glossaire de l'IA pour dirigeants et directions financières : quarante notions clés

Dans la plupart des comités de direction, le mot « intelligence artificielle » revient depuis un moment déjà, souvent sans que chacun mette la même chose derrière. Pour un dirigeant, un directeur financier (DAF), un associé de fonds d'investissement ou un expert-comptable, cette imprécision a des conséquences très concrètes : on valide des budgets sur la foi de présentations dont on ne maîtrise pas le vocabulaire, on confie des documents à des prestataires sans savoir précisément ce qu'ils deviennent, et on accepte des promesses dont on ne peut pas juger la crédibilité. Le problème n'est donc pas seulement l'ignorance de quelques termes. Il tient à l'impossibilité de poser les bonnes questions au bon moment, c'est-à-dire avant de décider et non après.

Ce glossaire répond à ce besoin. Il rassemble les notions les plus utilisées dans les projets d'IA, depuis les mots qui décrivent la technologie jusqu'à ceux qui encadrent son usage, comme la donnée personnelle, la traçabilité ou la supervision humaine. Chaque notion est définie avec des mots simples, rattachée à ce qu'elle change concrètement pour un dirigeant, illustrée par un exemple générique qui ne renvoie à aucune organisation réelle, puis reliée à une question de décision : que faut-il vérifier, qui doit valider et quel risque faut-il surveiller dans le temps. L'objectif n'est pas de transformer un dirigeant en ingénieur. Il s'agit de l'aider à demander les bonnes preuves et de distinguer une réponse solide d'une réponse de façade.

Ce texte se veut aussi un outil de travail. Les fiches sont indépendantes : vous pouvez les lire dans l'ordre pour bâtir un vocabulaire commun au sein de votre équipe, ou n'en consulter qu'une seule au moment où le sujet arrive sur la table. La section finale propose une checklist à imprimer, un glossaire récapitulatif et des réponses aux questions qui reviennent le plus souvent en comité.

Comment lire chaque fiche#

Chaque notion suit le même plan, pour que vous puissiez la retrouver rapidement et la comparer avec les autres.

• La définition. Elle décrit la notion en langage courant, sans formule mathématique. Lorsqu'une confusion est fréquente, elle précise aussi ce que la notion n'est pas, car beaucoup de malentendus viennent d'un même mot employé pour des réalités différentes.
• L'intérêt pour un dirigeant. Elle explique pourquoi la notion compte pour une décision d'investissement, de pilotage ou de contrôle, et non pour l'exécution technique. Un dirigeant n'a pas besoin de savoir comment un système a été entraîné, mais il doit savoir si cet entraînement a été documenté.
• L'exemple générique. Il illustre la notion dans une situation banale, volontairement éloignée de toute entreprise réelle. Il sert à se représenter le mécanisme avant d'en discuter avec un prestataire.
• La question de décision. Elle se décline toujours de la même façon : ce qu'il faut vérifier, la fonction qui doit valider, et le risque à surveiller dans le temps.

Quelques précisions de méthode complètent cette lecture. Les exemples sont génériques : ils ne citent ni client, ni fonds, ni personne, ni outil. Aucune valeur chiffrée n'est donnée, car les seuils dépendent de chaque contexte : lorsqu'une mesure est nécessaire, la fiche décrit la méthode ou le type d'indicateur à suivre. Enfin, les éléments juridiques sont présentés comme des principes. Ils ne remplacent pas l'avis d'un juriste, et toute obligation réglementaire doit être vérifiée avec lui avant d'être appliquée.

Modèles#

Cette partie présente les briques techniques. Vous n'avez pas à les construire, mais vous devez les comprendre pour évaluer ce qu'un prestataire vous propose, expliquer pourquoi un résultat varie d'une demande à l'autre et repérer les coûts qui n'apparaissent pas dans une première présentation. Les notions s'enchaînent : la première décrit le principe général, les suivantes précisent des objets de plus en plus concrets.

Apprentissage automatique#

L'apprentissage automatique (en anglais machine learning) désigne les méthodes par lesquelles un programme apprend des règles à partir d'exemples, au lieu de les recevoir écrites une à une par un développeur. On lui présente des cas déjà renseignés, par exemple des factures dont l'imputation comptable est connue, et il ajuste ses paramètres pour reproduire ces réponses sur des cas nouveaux. Le résultat de cet entraînement s'appelle un modèle, c'est-à-dire une fonction statistique dont la qualité dépend directement des exemples utilisés. Presque toutes les applications actuelles de l'IA reposent sur ce principe.

Intérêt pour le dirigeant. La performance d'une solution d'apprentissage automatique reflète surtout la qualité de ses exemples, bien plus que le code qui l'exécute. C'est donc sur les données qu'il faut poser les questions, et non sur la technique seule.

Exemple générique. Une entreprise veut classer automatiquement ses notes de frais. Elle fournit au système des notes déjà classées par ses collaborateurs, puis le laisse appliquer ce classement à de nouvelles notes.

Question de décision. Le système a-t-il appris sur des exemples représentatifs de notre activité ?

• Quoi vérifier : la provenance des exemples, leur ancienneté, leur couverture des cas rares et les consignes données à ceux qui les ont étiquetés.
• Qui valide : le DAF ou le responsable du contrôle interne, avec les personnes qui ont établi le classement de référence.
• Risque à surveiller : une bonne performance sur les cas courants qui masque une fragilité sur les cas inhabituels, souvent les plus coûteux.

Modèle de langage#

Un modèle de langage (en anglais large language model, souvent abrégé LLM) est un modèle d'apprentissage automatique entraîné sur de très grands volumes de texte pour prédire la suite la plus probable d'une séquence de mots ou de fragments de mots. Cette capacité simple, répétée à très grande échelle, lui permet de résumer, de traduire, de reformuler ou de répondre à une question. Il ne consulte pas une base de faits vérifiés : il produit ce qui semble plausible au regard de son entraînement et de la demande reçue. C'est pourquoi sa réponse peut être fluide et fausse à la fois.

Intérêt pour le dirigeant. Le modèle de langage est le moteur de la plupart des outils de texte récents. La question n'est pas seulement ce qu'il sait faire, mais où il s'exécute, avec quelles données il est connecté et à qui appartiennent les échanges.

Exemple générique. Un collaborateur demande à un outil de rédiger le brouillon d'une lettre à un client à partir de notes internes. Le texte obtenu est poli et bien structuré, mais il doit être relu, car rien ne prouve qu'il reprend exactement les notes.

Question de décision. Quel usage de texte confions-nous à un modèle de langage, et avec quel niveau de relecture ?

• Quoi vérifier : la liste des usages autorisés, les types d'informations qui peuvent être saisies, et l'existence d'une relecture humaine avant tout envoi à l'extérieur.
• Qui valide : le responsable de la sécurité des systèmes d'information et le juriste, dès que des données confidentielles sont en jeu.
• Risque à surveiller : la fuite d'informations sensibles par la saisie de documents non autorisés, et la diffusion d'un texte faux qui paraît fiable.

IA générative#

L'IA générative désigne les systèmes capables de produire un contenu nouveau (texte, image, son, code, tableau) à partir d'une demande, en s'appuyant sur des régularités apprises pendant leur entraînement. Les modèles de langage en sont la forme la plus répandue dans les entreprises. Le contenu produit n'est pas, en règle générale, une copie d'une base de documents : il a la forme de ce que le système a vu, sans en être la reproduction exacte. Cette souplesse explique à la fois son intérêt et les risques qu'elle fait peser sur la fiabilité.

Intérêt pour le dirigeant. Ce qui distingue l'IA générative de l'analyse traditionnelle, c'est qu'elle produit un contenu que l'entreprise devra ensuite utiliser, signer ou diffuser. La gouvernance change donc de nature : il ne suffit plus de vérifier un calcul, il faut vérifier l'objet produit et son statut.

Exemple générique. Une équipe demande la synthèse de plusieurs comptes rendus de réunion. Le système produit une note de quelques paragraphes, que la personne en charge compare aux comptes rendus avant de la diffuser.

Question de décision. Le contenu généré est-il traité comme un brouillon soumis à validation, ou comme un document définitif ?

• Quoi vérifier : que chaque type de production a un statut défini (brouillon, validé, diffusé) et que la personne qui la signe a relu les sources.
• Qui valide : le responsable métier concerné, et la direction juridique pour tout contenu qui engage l'entreprise.
• Risque à surveiller : la diffusion de contenus non vérifiés, alors que la responsabilité de ce qui est publié reste celle de l'entreprise.

Jeton#

Un jeton (en anglais token) est l'unité de texte qu'un modèle de langage lit et produit. Il ne correspond pas exactement à un mot : un mot courant peut valoir un seul jeton, un mot long, technique ou rare peut en valoir plusieurs, et la ponctuation compte aussi. Le texte est découpé en jetons avant d'être traité, puis le modèle raisonne sur cette suite. Les services de modèles de langage facturent souvent leur usage en jetons, ce qui rend la comparaison de plusieurs offres moins simple qu'il n'y paraît.

Intérêt pour le dirigeant. Le jeton est l'unité de compte de nombreux services. Un dirigeant qui compare des offres doit savoir que le volume consommé dépend de la longueur des demandes, des réponses et de l'historique transmis, et non seulement du nombre d'utilisateurs.

Exemple générique. Un texte riche en termes techniques, en noms propres ou en tableaux peut représenter un volume bien supérieur à celui d'un courriel ordinaire de même apparence. Un outil qui analyse un dossier long consommera donc nettement plus qu'un simple échange de messages.

Question de décision. Comment l'usage est-il mesuré, et sur quelles hypothèses de volume repose notre budget ?

• Quoi vérifier : l'unité de facturation, la manière dont l'historique de conversation est compté, et la différence entre texte saisi et texte produit.
• Qui valide : le DAF, avec l'équipe qui connaît les usages réels.
• Risque à surveiller : un budget établi sur des tests trop simples, qui se dégrade dès que les demandes deviennent longues ou nombreuses.

Fenêtre de contexte#

La fenêtre de contexte est la quantité maximale de texte qu'un modèle de langage peut prendre en compte en une seule fois, mesurée en jetons. Elle englobe la consigne, les documents fournis, l'historique de l'échange et la réponse en cours de rédaction. Au-delà de cette limite, les informations excédentaires ne sont pas lues et ne peuvent donc pas influencer la réponse. Une fenêtre plus large permet de traiter des dossiers plus longs, mais elle n'assure pas que le modèle exploitera correctement chaque passage.

Intérêt pour le dirigeant. La fenêtre de contexte conditionne ce qu'un outil peut analyser d'un seul trait. Elle est souvent la cause invisible de réponses incomplètes : le système n'a pas oublié une partie du dossier, il ne l'a jamais reçue.

Exemple générique. On demande à un outil de comparer les clauses de plusieurs contrats. Si l'ensemble dépasse la capacité de lecture, les derniers documents ne sont pas pris en compte, et la comparaison paraît pourtant complète.

Question de décision. Le dossier tient-il dans la fenêtre de lecture, et le résultat indique-t-il clairement ce qui a été analysé ?

• Quoi vérifier : la taille typique des dossiers traités, la méthode de découpage éventuellement utilisée, et la mention explicite des documents non lus dans chaque restitution.
• Qui valide : le responsable du projet métier, qui connaît l'exhaustivité attendue.
• Risque à surveiller : une conclusion présentée comme exhaustive alors qu'elle repose sur une partie seulement du dossier.

Réglage fin (fine-tuning)#

Le réglage fin, souvent appelé par son nom anglais fine-tuning, consiste à poursuivre l'entraînement d'un modèle déjà existant sur un jeu d'exemples propres à un domaine, à un vocabulaire ou à un format de réponse. Le modèle conserve ses capacités générales et en acquiert de nouvelles, par exemple une manière constante de structurer une note. Cette opération demande des données soigneusement préparées et une évaluation rigoureuse après coup. Elle ne sert pas à apprendre au modèle des faits récents, pour lesquels d'autres méthodes sont généralement mieux adaptées.

Intérêt pour le dirigeant. Le réglage fin est souvent présenté comme la façon d'adapter l'IA à l'entreprise. C'est pourtant un investissement lourd en données, en compétences et en maintenance, qui doit être justifié face à des alternatives plus légères, notamment la génération augmentée par récupération décrite plus loin.

Exemple générique. Une société de gestion souhaite que ses notes de synthèse suivent toujours la même structure et le même vocabulaire. Un réglage fin sur des notes validées peut stabiliser ce format, mais il ne rend pas le modèle exact sur les données de marché du moment.

Question de décision. Le besoin justifie-t-il de modifier le modèle lui-même, plutôt que de fournir un meilleur contexte à un modèle existant ?

• Quoi vérifier : les alternatives réellement testées, la qualité et la représentativité des exemples d'adaptation, et le plan de reprise lorsque le modèle de base évolue.
• Qui valide : la direction des systèmes d'information, avec le métier responsable de la validation des exemples.
• Risque à surveiller : une dépendance coûteuse à une version précise du modèle, et des exemples d'adaptation qui contiennent des informations confidentielles.

API#

Une API (interface de programmation, en anglais application programming interface) est un point d'entrée standardisé par lequel un logiciel peut appeler un autre. Dans le domaine de l'IA, elle permet à votre système de transmettre une demande à un modèle hébergé ailleurs, puis de recevoir la réponse, sans héberger le modèle soi-même. Les échanges suivent des règles documentées, qui précisent les formats, les droits d'accès et les limites d'usage. L'API est donc le lien technique par lequel des données de l'entreprise sortent vers un prestataire, ce qui en fait un point de contrôle majeur.

Intérêt pour le dirigeant. Une API n'est pas un détail d'intégration. C'est la porte par laquelle les données transitent, et c'est aussi le point où se joue la dépendance au prestataire, car changer de fournisseur exige souvent de reprendre une partie des connexions.

Exemple générique. Un logiciel de gestion des notes de frais envoie chaque justificatif à un modèle par l'intermédiaire d'une interface, reçoit une catégorie proposée et l'affiche au collaborateur pour validation.

Question de décision. Quelles données transitent par cette interface, où sont-elles traitées, et que devient le contrat si nous changeons de prestataire ?

• Quoi vérifier : la liste des champs transmis, la localisation du traitement, les règles de conservation appliquées par le prestataire et les conditions de réversibilité, c'est-à-dire les modalités de sortie du service.
• Qui valide : le directeur des systèmes d'information (DSI) et le délégué à la protection des données (DPO).
• Risque à surveiller : une transmission de données personnelles plus large que nécessaire, et une dépendance technique difficile à défaire.

Données#

Les données sont la matière première de tout projet d'IA, et la première source de risque juridique et opérationnel. Les notions de cette partie aident à distinguer ce qui sert à construire un système, ce qui lui est fourni pendant son usage et ce qui doit être protégé, anonymisé ou exclu.

Données d'entraînement#

Les données d'entraînement sont l'ensemble des exemples utilisés pour construire un modèle d'apprentissage automatique. Elles peuvent être produites par l'entreprise, achetées auprès d'un tiers, collectées en ligne ou fournies par un prestataire. Leur contenu détermine ce que le système sait faire, ce qu'il rate et les déformations qu'il peut reproduire. Un modèle ne peut pas être meilleur que la représentation du réel contenue dans ses données d'entraînement.

Intérêt pour le dirigeant. La question des données d'entraînement est à la fois une question de propriété, de droit et de qualité. Il faut savoir si l'on a le droit de les utiliser, si elles sont représentatives et si leur origine est documentée.

Exemple générique. Un cabinet veut un outil qui repère les anomalies dans des déclarations. Si les exemples d'entraînement ne contiennent que des dossiers ordinaires, l'outil connaîtra mal les situations inhabituelles, qui sont précisément celles qu'on veut détecter.

Question de décision. Savons-nous d'où viennent les données qui ont servi à construire le système, et sont-elles adaptées à notre activité ?

• Quoi vérifier : l'origine de chaque jeu de données, les droits d'usage associés, la présence éventuelle de données personnelles et la représentation des cas rares.
• Qui valide : le juriste ou le DPO pour les droits, le métier pour la représentativité.
• Risque à surveiller : un système qui reproduit les angles morts de ses données, ou qui a été entraîné sur des données dont l'usage n'était pas permis.

Données synthétiques#

Les données synthétiques sont des données générées artificiellement pour imiter les propriétés statistiques de données réelles, sans reproduire directement les enregistrements d'origine. On les utilise pour tester ou entraîner un système lorsque les vraies données sont rares, sensibles ou difficiles à exploiter. Leur qualité dépend entièrement de la fidélité du générateur : un générateur mal calibré produit des données plausibles mais trompeuses. Elles ne suppriment pas le besoin de contrôle, elles le déplacent.

Intérêt pour le dirigeant. Les données synthétiques peuvent permettre des tests sans exposer de données réelles. Elles ne règlent pas pour autant la question de conformité : il faut savoir si elles ont été dérivées de données personnelles et si elles peuvent encore ramener à une personne.

Exemple générique. Une équipe veut tester un outil de traitement de dossiers sans manipuler de vrais dossiers clients. Elle génère des dossiers fictifs qui respectent les mêmes types de montants, de dates et de structures, puis vérifie que les mêmes erreurs apparaissent.

Question de décision. Les données de test sont-elles réellement anonymes, et représentent-elles les situations que nous devons maîtriser ?

• Quoi vérifier : la méthode de génération, le risque de reconstitution de personnes réelles et la couverture des cas difficiles.
• Qui valide : le DPO pour l'absence de réidentification, le responsable métier pour la représentativité.
• Risque à surveiller : un faux sentiment de sécurité, avec des tests validés sur des données trop lisses pour révéler les vrais échecs.

Donnée personnelle#

Une donnée personnelle est toute information qui se rapporte à une personne physique identifiée ou identifiable, directement (un nom, une adresse) ou indirectement (une combinaison d'éléments qui permet de la reconnaître). Le RGPD l'encadre strictement : sa collecte, son usage et sa conservation doivent, selon les cas, reposer sur une base légale à faire confirmer par un juriste, une finalité précise et des mesures de sécurité adaptées. Un texte, une image, un enregistrement ou une ligne de tableau peuvent en contenir, parfois sans que personne s'en rende compte.

Intérêt pour le dirigeant. Dès qu'un projet d'IA manipule des informations sur des clients, des salariés ou des interlocuteurs, il peut entrer dans le champ du RGPD, à confirmer avec un juriste. Le dirigeant doit donc savoir où ces données sont saisies, qui peut les voir et si elles servent à entraîner un outil tiers.

Exemple générique. Un collaborateur colle le courriel d'un client dans un outil de rédaction pour obtenir une réponse. Le message contient un nom, une adresse et un contexte personnel : ce sont des données personnelles, transmises à un service qui peut être situé hors de l'entreprise.

Question de décision. Quelles données personnelles entrent dans le système, et sur quelle base les traitons-nous ?

• Quoi vérifier : les champs collectés, la finalité déclarée, les accès, la localisation du traitement et la nécessité d'une analyse d'impact sur la protection des données lorsque le risque est élevé.
• Qui valide : le DPO, avec la fonction métier qui porte la finalité.
• Risque à surveiller : une saisie spontanée de données personnelles par les équipes, en dehors de tout cadre validé.

Anonymisation#

L'anonymisation consiste à transformer des données personnelles de façon qu'il ne soit plus possible, par des moyens raisonnables, de rattacher une information à une personne. Une donnée réellement anonyme peut, selon les cas, sortir du champ du RGPD, point à faire confirmer par un juriste. Le sujet est plus délicat qu'il n'y paraît, car des données qui semblent anonymes peuvent être réidentifiées par recoupement avec d'autres sources. L'anonymisation est donc un résultat à démontrer, et non une case à cocher.

Intérêt pour le dirigeant. L'anonymisation est souvent présentée comme l'argument qui permet d'exploiter des données sans multiplier les autorisations. Elle n'est utile que si elle résiste à un recoupement réaliste, et la charge de cette démonstration pèse sur l'organisation qui la revendique.

Exemple générique. Une étude analyse les habitudes de règlement de ses clients. Retirer les noms ne suffit pas si les dates exactes, le lieu et la nature d'une prestation permettent de retrouver une personne précise dans un petit groupe.

Question de décision. Peut-on démontrer que ces données ne permettent plus d'identifier qui que ce soit, même en les croisant avec ce qui est accessible ?

• Quoi vérifier : les champs supprimés et ceux rendus moins précis, la taille des groupes restants, et le test de recoupement réalisé avant tout usage.
• Qui valide : le DPO, idéalement avec un expert indépendant pour les jeux de données sensibles.
• Risque à surveiller : une réidentification par croisement, et une réutilisation des données au-delà de la finalité prévue.

Pseudonymisation#

La pseudonymisation remplace les identifiants directs (nom, numéro de dossier, adresse) par des codes de substitution, tandis que la table de correspondance est conservée séparément et protégée. Contrairement à l'anonymisation, elle ne supprime pas le caractère personnel des données : celui qui détient la correspondance peut toujours revenir à la personne. Le RGPD la présente comme une mesure de sécurité utile, qui limite l'exposition, dont l'effet juridique reste à confirmer avec un juriste.

Intérêt pour le dirigeant. La pseudonymisation est un outil de réduction des risques, dont l'effet juridique doit être confirmé par un juriste. Elle permet à des équipes de travailler sur des données moins sensibles, tout en gardant la possibilité de retrouver un dossier lorsque c'est nécessaire, par exemple pour un contrôle.

Exemple générique. Un service de gestion remplace les noms des salariés par des identifiants internes avant de transmettre des données de temps de travail à un outil d'analyse. Seule la personne responsable du lien peut revenir au nom.

Question de décision. Qui détient la correspondance entre les codes et les personnes, et cette séparation est-elle réellement effective ?

• Quoi vérifier : l'emplacement de la table de correspondance, les droits d'accès, la facilité avec laquelle les codes pourraient être reconstitués et la journalisation des consultations.
• Qui valide : le responsable de la sécurité, avec le DPO.
• Risque à surveiller : un code facile à reconstituer, ou une clé stockée au même endroit que les données, ce qui annule la protection.

Base de connaissances#

Une base de connaissances est un ensemble organisé de documents et d'informations (procédures, notes, questions fréquentes, contrats types, historiques de dossiers) que l'entreprise rend consultable de façon structurée. Dans un projet d'IA, elle sert de source de référence : le système s'appuie sur elle pour répondre, au lieu de se fier uniquement à ce qu'il a appris pendant son entraînement. La qualité d'une base de connaissances dépend moins de sa taille que de sa fraîcheur, de son exactitude et de la clarté de ses responsables.

Intérêt pour le dirigeant. La base de connaissances est souvent le véritable actif informationnel d'une organisation, et c'est souvent le point le plus négligé. Il faut savoir qui met à jour les contenus, qui décide de ce qui est publié et quelle version fait foi lorsque deux documents se contredisent.

Exemple générique. Un cabinet rassemble ses notes internes sur les régimes fiscaux qui reviennent souvent. Un outil s'appuie sur ces notes pour répondre aux questions des collaborateurs, en indiquant la note utilisée.

Question de décision. Qui est responsable de l'exactitude de chaque document de référence, et comment savons-nous qu'il est à jour ?

• Quoi vérifier : la date de dernière revue, le propriétaire nommé de chaque contenu, et la procédure de retrait des documents obsolètes.
• Qui valide : le responsable métier de chaque domaine, avec une fonction transverse qui contrôle la cohérence de l'ensemble.
• Risque à surveiller : une réponse fluide appuyée sur une procédure périmée, sans que l'utilisateur sache qu'elle l'est.

OCR (reconnaissance optique de caractères)#

L'OCR (en anglais optical character recognition) est une technique qui transforme une image contenant du texte, comme un scan ou une photo de document, en texte exploitable par un logiciel. Elle identifie les lettres et les chiffres, puis reconstitue la mise en page lorsque c'est possible. Les systèmes récents combinent l'OCR avec des modèles de compréhension, ce qui permet d'aller au-delà de la simple lecture. Un caractère mal reconnu peut toutefois modifier un montant ou un nom sans que rien ne le signale.

Intérêt pour le dirigeant. Pour une direction financière, l'OCR conditionne la fiabilité de toute la chaîne qui suit : saisie, rapprochement, contrôle. Il faut donc mesurer ce que le système fait des documents dégradés, manuscrits ou mal numérisés, et ne pas se fier à une démonstration réalisée sur des documents propres.

Exemple générique. Un service numérise des justificatifs de dépenses. Sur un ticket froissé, un caractère est confondu avec un autre, et le montant extrait est faux. Sans contrôle, l'erreur passe dans la comptabilité.

Question de décision. Comment vérifions-nous les données extraites d'un document avant qu'elles n'alimentent un calcul ou une écriture ?

• Quoi vérifier : la mesure de précision de l'extraction sur des documents représentatifs, incluant les cas les plus dégradés, et la présence de contrôles de cohérence (total, format, rapprochement).
• Qui valide : le responsable comptable, sur un échantillon de documents réels.
• Risque à surveiller : une erreur silencieuse sur un montant, un nom ou une date, qui se propage ensuite dans les états financiers.

Usage#

Cette partie décrit les façons dont l'IA entre concrètement dans le travail quotidien. Les notions sont présentées de la plus simple à la plus autonome : une consigne donnée à un modèle, un assistant qui accompagne une personne, un système qui agit seul sur des étapes d'un processus. Plus le système agit seul, plus la supervision doit être précise.

Prompt#

Un prompt est la consigne ou la demande adressée à un modèle de langage. Il peut contenir des instructions, du contexte, des exemples et des documents, et l'ordre dans lequel ces éléments sont présentés influence le résultat. Les entreprises utilisent souvent des prompts standardisés, rédigés et testés par une équipe, pour que les réponses restent cohérentes d'un utilisateur à l'autre. Un prompt est donc un élément de processus, et non une simple question posée à une machine.

Intérêt pour le dirigeant. Un prompt bien rédigé est une forme de procédure écrite. Il faut savoir s'il existe des prompts validés pour les usages sensibles, qui les a rédigés et comment on sait qu'ils donnent un résultat conforme.

Exemple générique. Pour analyser des contrats, une équipe rédige un prompt qui demande d'extraire la durée d'engagement, le préavis et les clauses de résiliation, avec la mention « non trouvé » lorsque l'information est absente. Ce prompt est ensuite testé sur un ensemble de contrats déjà analysés.

Question de décision. Nos usages critiques reposent-ils sur des consignes écrites, testées et versionnées, ou sur l'habileté de chaque utilisateur ?

• Quoi vérifier : l'existence d'une bibliothèque de prompts validés, leur historique de modification et les tests de non-régression après chaque changement.
• Qui valide : le responsable métier et le responsable du contrôle interne.
• Risque à surveiller : une variation silencieuse des résultats selon la formulation, et des consignes qui contournent les règles de confidentialité.

Génération augmentée par récupération (RAG)#

La génération augmentée par récupération, en anglais retrieval-augmented generation (RAG), consiste à chercher d'abord les passages pertinents dans une base de documents, puis à les transmettre au modèle avec la question. Le modèle répond à partir de ces extraits, ce qui permet d'ancrer la réponse dans des sources identifiables et récentes, sans modifier le modèle lui-même. Le système peut aussi citer ses sources, ce qui facilite la vérification. Sa qualité dépend de deux maillons : la recherche doit trouver les bons passages, et le modèle doit les lire correctement.

Intérêt pour le dirigeant. La génération augmentée par récupération est souvent l'approche la plus adaptée lorsque l'entreprise veut interroger ses propres documents sans les intégrer à un modèle. Elle déplace la question de la fiabilité vers la qualité de la base documentaire et de la recherche, ce qui se prête mieux à un contrôle.

Exemple générique. Un collaborateur interroge les procédures internes sur les notes de frais. Le système retrouve la procédure applicable, affiche le passage utilisé et répond. Si aucune procédure ne correspond, il doit l'indiquer au lieu d'inventer une règle.

Question de décision. Quand la réponse est fausse, sait-on si c'est la recherche qui a échoué ou le modèle qui a mal interprété le passage ?

• Quoi vérifier : la pertinence des passages retournés sur un ensemble de questions dont la réponse est connue, la présence de citations consultables, et le comportement du système face à une question sans réponse dans la base.
• Qui valide : le responsable de la base de connaissances, avec le métier concerné.
• Risque à surveiller : des réponses appuyées sur une source ancienne ou mal choisie, présentées avec une apparence d'autorité.

Agent IA#

Un agent IA est un système qui ne se contente pas de répondre : il planifie une suite d'actions, utilise des outils (recherche dans une base, envoi d'une demande, lecture d'un fichier), observe les résultats et ajuste la suite. Son autonomie peut être réelle ou limitée à des étapes encadrées. Plus il dispose de droits d'écriture sur des systèmes, plus une erreur peut avoir des effets concrets. La notion recouvre donc une large gamme de niveaux d'autonomie, et il faut toujours préciser celui qui est visé.

Intérêt pour le dirigeant. Un agent déplace la question du contenu vers l'action. La vraie question n'est pas « que dit-il ? », mais « que peut-il faire, avec quels droits, et qui peut arrêter une action en cours ? ».

Exemple générique. Un agent est chargé de préparer les rapprochements bancaires de la période. Il lit les relevés, propose les correspondances et prépare les écritures. Il ne valide pas les écritures : une personne le fait après examen des écarts.

Question de décision. Quelles actions l'agent est-il autorisé à accomplir seul, et quels points imposent une validation humaine avant exécution ?

• Quoi vérifier : la liste explicite des outils accessibles, les droits d'écriture accordés, les journaux d'actions et le mécanisme d'arrêt.
• Qui valide : la direction des systèmes d'information et le responsable du contrôle interne, avant toute mise en production.
• Risque à surveiller : une chaîne d'actions qui s'enchaîne sans contrôle, ou une autorisation accordée au-delà du besoin réel.

Copilote#

Un copilote est un assistant intégré à un outil de travail, qui accompagne la personne sans la remplacer. Il suggère, reformule, complète ou explique, mais la décision et l'action restent à l'utilisateur. Le terme est devenu courant pour désigner les assistants de rédaction, de recherche ou d'analyse disponibles au sein des logiciels métiers. Son intérêt tient moins à sa puissance qu'à sa place dans le processus et à la clarté des limites qu'il respecte.

Intérêt pour le dirigeant. Le copilote est souvent le premier usage déployé, car il paraît peu risqué. Il pose pourtant des questions réelles : quelles données voit-il, qui l'a configuré, et les utilisateurs savent-ils qu'une suggestion n'est pas une vérité validée ?

Exemple générique. Dans un logiciel de consolidation, un copilote propose une explication des écarts entre deux périodes. L'analyste peut accepter, modifier ou rejeter la proposition, et seule son écriture finale est enregistrée.

Question de décision. Le copilote améliore-t-il réellement le travail de l'équipe, et les utilisateurs savent-ils quand se méfier de ses suggestions ?

• Quoi vérifier : les données auxquelles il accède, les cas d'usage où il est recommandé, et la formation aux limites de l'outil.
• Qui valide : le responsable métier, avec la fonction qualité ou contrôle.
• Risque à surveiller : une confiance excessive qui conduit à accepter sans relire, surtout sur des sujets où l'erreur est discrète.

Automatisation#

L'automatisation consiste à confier à un système l'exécution répétée d'une tâche selon des règles définies. Elle peut être classique, fondée sur des règles explicites (si telle condition est remplie, alors tel traitement est appliqué), ou s'appuyer sur de l'IA pour traiter des entrées variées, comme des courriels ou des documents. Automatiser ne signifie pas supprimer le contrôle : celui-ci se déplace vers la conception des règles, la surveillance des exceptions et la traçabilité des exécutions.

Intérêt pour le dirigeant. L'automatisation est un choix d'organisation autant qu'un choix technique. Elle doit être décidée à partir du processus lui-même : ce qui est répétitif, ce qui est stable et ce qui doit rester sous décision humaine.

Exemple générique. Un cabinet automatise le classement des courriels entrants par type de demande. Les messages ambigus sont envoyés dans une file de traitement manuel, et non classés de force dans une catégorie.

Question de décision. Quel traitement est automatisé, quelles exceptions sont détectées, et qui reprend la main quand le système ne sait pas faire ?

• Quoi vérifier : la liste des cas automatisés, le critère de doute au-delà duquel le dossier bascule vers un traitement humain, et l'historique des exécutions.
• Qui valide : le propriétaire du processus métier, avec le contrôle interne.
• Risque à surveiller : une erreur répétée à grande échelle, car l'automatisation multiplie aussi bien les bons résultats que les mauvais.

Automatisation robotisée des processus (RPA)#

L'automatisation robotisée des processus, en anglais robotic process automation (RPA), désigne des logiciels qui reproduisent les gestes d'un utilisateur sur une interface : cliquer, copier un champ, saisir une valeur, télécharger un fichier. Elle est particulièrement utile lorsque les applications anciennes n'offrent pas d'interface de programmation. Elle devient fragile lorsque l'écran change, et elle peut être combinée à de l'IA pour lire des documents ou prendre des décisions simples.

Intérêt pour le dirigeant. La RPA est souvent présentée comme une solution simple, mais elle crée une dépendance aux écrans et aux procédures existantes. Il faut savoir qui maintient les robots, ce qui se passe lors d'une mise à jour d'application et quels accès ils utilisent.

Exemple générique. Un robot récupère chaque relevé disponible sur un portail et le saisit dans un outil de suivi. Lorsque le portail change de présentation, le robot s'arrête, et une alerte doit prévenir l'équipe.

Question de décision. Qui maintient ces robots, comment sont-ils surveillés, et que se passe-t-il lorsqu'une application évolue ?

• Quoi vérifier : les identifiants utilisés (des comptes dédiés et contrôlés), la journalisation des actions et la procédure de reprise en cas d'arrêt.
• Qui valide : la direction des systèmes d'information et le contrôle interne.
• Risque à surveiller : des accès trop larges accordés à un robot, et une dépendance qui devient invisible tant qu'elle ne tombe pas en panne.

Cas d'usage#

Un cas d'usage est une application précise de l'IA à un problème métier identifié, décrite avec son contexte, ses utilisateurs, ses données, ses résultats attendus et ses limites. C'est l'unité pertinente de décision : on ne décide pas d'« adopter l'IA », on décide d'utiliser un système pour une tâche donnée. Un bon cas d'usage se formule en une phrase compréhensible par un non-spécialiste, et il comporte une façon de vérifier qu'il a fonctionné.

Intérêt pour le dirigeant. Le cas d'usage est l'outil de priorisation du dirigeant. Il permet de comparer des projets sur des critères communs : l'importance du problème, la qualité des données, le niveau de risque et la capacité à mesurer le résultat.

Exemple générique. Plusieurs propositions arrivent au comité : classer des factures fournisseurs, rédiger des réponses types, anticiper les retards de règlement. Chacune est reformulée en cas d'usage avec son utilisateur, ses données et son critère de réussite, puis comparée aux autres.

Question de décision. Ce cas d'usage est-il décrit assez précisément pour que quelqu'un puisse dire s'il a réussi ?

• Quoi vérifier : l'énoncé du problème, la population concernée, le critère de réussite, les données nécessaires et ce que le système ne doit jamais faire.
• Qui valide : le sponsor métier, avec le DAF ou la direction générale selon l'enjeu.
• Risque à surveiller : un projet lancé sur une ambition vague, sans critère permettant de dire qu'il a échoué.

Extraction d'information#

L'extraction d'information consiste à repérer et à isoler des éléments précis dans un texte ou un document : une date d'échéance, un montant, le nom d'une partie, une clause, un identifiant. Elle transforme un document non structuré en champs exploitables dans un tableau ou dans un outil. Un système d'IA y parvient en lisant le texte et en appliquant des règles apprises ou décrites explicitement. Le résultat doit être accompagné de l'endroit du document d'où provient chaque information, pour pouvoir être vérifié.

Intérêt pour le dirigeant. L'extraction est l'un des usages les plus concrets pour les fonctions financières, car elle alimente des processus existants. Le dirigeant doit surtout s'intéresser à la manière dont les erreurs sont détectées avant d'entrer dans les comptes ou dans les analyses.

Exemple générique. À partir d'un ensemble de contrats de location, le système relève la date de fin, le montant mensuel et la clause d'indexation, puis les place dans un tableau dont chaque ligne renvoie à la page du contrat.

Question de décision. Chaque information extraite est-elle reliée à sa source et soumise à un contrôle proportionné à son importance ?

• Quoi vérifier : la présence d'une référence source pour chaque champ, les règles de contrôle (cohérence, format, rapprochement), et les cas où le système indique qu'il ne sait pas.
• Qui valide : le responsable de la fonction qui consomme les données.
• Risque à surveiller : une information fausse mais plausible, extraite d'une mauvaise version du document.

Classification#

La classification consiste à attribuer une catégorie à un élément, selon un ensemble de catégories prédéfinies : une facture à un compte, un courriel à un type de demande, une transaction à un niveau de risque. Elle repose souvent sur l'apprentissage automatique, ou sur l'IA générative guidée par des consignes. La qualité d'un classement se juge à sa cohérence avec les décisions humaines de référence, et à la manière dont il traite les cas qui n'entrent dans aucune catégorie.

Intérêt pour le dirigeant. Un système de classement reproduit une grille de lecture, donc une vision de l'activité. Le dirigeant doit s'assurer que cette grille est validée par ceux qui l'utilisent, et que les catégories restent stables dans le temps.

Exemple générique. Une société de services classe les demandes de ses clients entre plusieurs catégories. Une demande qui ne correspond à aucune catégorie est envoyée vers une file de qualification, plutôt que rangée de force dans la catégorie la moins mauvaise.

Question de décision. Qui définit les catégories, et comment vérifions-nous que le classement reste fidèle aux décisions humaines ?

• Quoi vérifier : le référentiel de catégories, la méthode de comparaison avec un classement de référence, et la gestion des cas hors catégorie.
• Qui valide : le responsable métier et le contrôle de gestion pour les catégories comptables.
• Risque à surveiller : une dérive silencieuse des catégories, ou un classement qui favorise une catégorie par défaut.

Résumé automatique#

Le résumé automatique produit une version plus courte d'un document, en conservant ses idées principales. Il peut être extractif, en sélectionnant des phrases existantes, ou génératif, en reformulant le contenu. Le second type est plus souple, mais il peut omettre une nuance ou introduire une formulation qui modifie le sens. Un résumé est donc une interprétation du document, et non le document lui-même.

Intérêt pour le dirigeant. Le résumé fait gagner en lisibilité, mais il transfère une part de jugement à l'outil. La question est de savoir ce qui a été omis, et si les décisions se prennent sur le résumé ou sur la source.

Exemple générique. Un comité reçoit le résumé d'un long rapport d'audit. Une recommandation qui dépend d'une réserve formulée dans une annexe risque de disparaître du résumé, alors qu'elle change la portée de la conclusion.

Question de décision. Le résumé renvoie-t-il vers les passages sources, et les décisions s'appuient-elles toujours sur le document original ?

• Quoi vérifier : la présence de renvois vers les passages, la comparaison entre résumé et source sur les points sensibles, et la mention des éléments exclus.
• Qui valide : l'auteur du document source et la personne qui présente la décision.
• Risque à surveiller : une omission de réserves, d'exceptions ou de conditions qui modifie le sens sans que personne ne le remarque.

Qualité et risque#

Un système d'IA peut être utile et défaillant à la fois. Cette partie rassemble les notions qui permettent de décrire les défaillances, de les rendre visibles et de décider qui en répond. Elle ne traite pas seulement de l'erreur technique : elle concerne aussi les biais, la traçabilité des décisions et la capacité d'une personne à reprendre la main.

Hallucination#

Une hallucination désigne une réponse produite par un modèle qui est fausse, inventée ou non fondée sur ses sources, mais présentée avec une apparente assurance. Ce n'est pas un bug isolé : elle découle de la nature même des modèles de langage, qui produisent ce qui est plausible plutôt que ce qui est vérifié. Une hallucination peut prendre la forme d'une référence inexistante, d'un chiffre erroné, d'une décision de justice fictive ou d'un résumé qui ajoute une information absente de la source. Le risque augmente lorsque la question touche à un domaine peu documenté ou lorsque l'utilisateur ne peut pas vérifier.

Intérêt pour le dirigeant. L'hallucination est le risque central de la génération de texte, car elle rend l'erreur convaincante. La question n'est pas de savoir si le système se trompe, mais dans quels cas il se trompe et comment l'erreur est détectée avant d'avoir un effet.

Exemple générique. Un outil de rédaction cite une disposition juridique qui n'existe pas, avec un intitulé plausible. Le relecteur qui connaît le domaine repère l'erreur, mais un relecteur pressé pourrait la laisser passer.

Question de décision. Comment détectons-nous une réponse fausse avant qu'elle ne soit utilisée, et quels types de sorties sont interdits sans vérification ?

• Quoi vérifier : la présence de sources pour chaque affirmation factuelle, le test du système sur des questions dont la réponse est connue, et son comportement face à une question sans réponse dans les documents.
• Qui valide : le responsable métier, et un relecteur indépendant pour les contenus qui engagent l'entreprise.
• Risque à surveiller : une citation inventée, une donnée chiffrée inexacte ou une conclusion juridique présentée comme établie.

Biais#

Un biais est une déformation systématique d'un système, qui le conduit à traiter de façon inégale certaines situations, certains groupes ou certains types de cas. Il peut provenir des données d'entraînement, de la manière dont le problème a été formulé, des choix de mesure ou de l'usage fait du résultat. Un biais n'est pas toujours intentionnel, et il n'apparaît pas forcément dans une moyenne globale : il se révèle souvent lorsqu'on regarde des sous-populations. La détection suppose donc de découper les résultats selon les catégories pertinentes.

Intérêt pour le dirigeant. Dans une direction financière, les biais peuvent produire des décisions de crédit, de recrutement ou de contrôle plus défavorables à certains profils, avec des conséquences juridiques et réputationnelles. Le dirigeant doit exiger qu'on lui montre les résultats découpés, et non seulement un score global.

Exemple générique. Un outil qui priorise des dossiers à contrôler affiche un score global satisfaisant. En découpant les résultats par type de dossier, l'équipe découvre que les dossiers d'un type peu fréquent sont systématiquement moins bien traités.

Question de décision. Les résultats ont-ils été analysés par sous-populations, et que fait-on des écarts observés ?

• Quoi vérifier : la liste des découpages pertinents, l'écart constaté entre groupes, et l'existence d'une décision documentée face à cet écart.
• Qui valide : le responsable de la conformité et un représentant du métier concerné.
• Risque à surveiller : une discrimination indirecte, invisible dans les moyennes mais identifiable par les personnes concernées ou lors d'un contrôle.

Explicabilité#

L'explicabilité désigne la capacité à expliquer, de façon compréhensible, pourquoi un système a produit tel résultat. Elle va de la justification simple (les critères qui ont pesé) à l'analyse technique du fonctionnement interne, qui reste difficile pour les modèles très complexes. Il faut distinguer l'explication offerte à l'utilisateur, celle destinée à l'auditeur et celle qui sert à corriger le système. Une explication plausible n'est pas forcément exacte : elle doit aussi être testée.

Intérêt pour le dirigeant. Un dirigeant doit pouvoir justifier une décision devant un client, un salarié, un auditeur ou un régulateur. Si un système ne sait pas expliquer ce qu'il a fait, la décision reste difficile à défendre, même si elle est statistiquement pertinente.

Exemple générique. Un outil recommande de contrôler une note de frais. L'interface indique les éléments qui ont motivé la recommandation : un montant inhabituel pour la catégorie, un justificatif incomplet. L'utilisateur peut vérifier chacun de ces éléments.

Question de décision. Pouvons-nous expliquer une décision à la personne concernée, avec des éléments qui correspondent réellement au calcul effectué ?

• Quoi vérifier : le niveau d'explication fourni à chaque public, la cohérence de cette explication avec le fonctionnement réel, et la documentation des limites du système.
• Qui valide : le DPO pour les décisions automatisées concernant des personnes, et le juriste pour les motifs à communiquer.
• Risque à surveiller : une justification de façade, construite après coup, qui ne correspond pas au mécanisme réellement utilisé.

Traçabilité#

La traçabilité est la capacité à reconstituer l'historique d'un résultat : quelles données ont été utilisées, quelle version du modèle ou de la consigne a produit la réponse, qui l'a validée et à quel moment. Elle repose sur des journaux conservés de façon fiable, des versions identifiées des composants et des règles de conservation claires. Sans traçabilité, il est impossible de répondre après coup à une question simple : pourquoi a-t-on décidé cela ?

Intérêt pour le dirigeant. La traçabilité est ce qui permet de contrôler un système dans le temps. Elle permet de rendre une utilisation opaque auditable, et elle aide l'entreprise à établir la responsabilité d'une décision lorsque cela est nécessaire.

Exemple générique. Un service utilise un modèle pour proposer des imputations comptables. Pour chaque proposition, le journal conserve la version du modèle, la consigne utilisée, la donnée d'entrée et la personne qui a accepté ou corrigé la proposition.

Question de décision. Pouvons-nous reconstituer, pour une décision donnée, toute la chaîne qui y a conduit ?

• Quoi vérifier : les journaux conservés, la séparation entre données d'entrée et sorties, les versions identifiées et les règles de conservation fixées par la politique interne.
• Qui valide : le responsable du contrôle interne, avec le commissaire aux comptes lors d'une revue, et le DPO pour les journaux qui contiennent des données personnelles.
• Risque à surveiller : des journaux incomplets, ou des journaux qui contiennent eux-mêmes des données sensibles et deviennent un risque de fuite.

Supervision humaine#

La supervision humaine désigne le dispositif par lequel une personne compétente garde la capacité de comprendre, de contrôler et, si nécessaire, d'arrêter ou de corriger le fonctionnement d'un système. Elle ne consiste pas à relire toutes les sorties, ce qui serait souvent irréaliste, mais à définir les points de contrôle, les seuils d'alerte et les pouvoirs d'intervention. Ce principe figure dans les textes européens sur l'IA pour les systèmes à risque, à faire confirmer par un juriste.

Intérêt pour le dirigeant. La supervision humaine est la réponse concrète à la question « qui décide ? ». Elle doit être désignée nommément et disposer du temps, des informations et de l'autorité nécessaires. Une relecture de principe, sans moyens ni pouvoir d'arrêt, n'est pas une supervision.

Exemple générique. Un système propose la validation automatique de petites dépenses. Toute proposition au-delà d'un montant défini par la politique interne, ou présentant une anomalie, est orientée vers une personne qui peut la rejeter sans avoir à justifier son désaccord auprès de l'outil.

Question de décision. Qui peut arrêter le système, qui le corrige, et avec quel niveau d'information ?

• Quoi vérifier : les points de contrôle nommés, les seuils qui déclenchent une escalade, la formation des superviseurs et la capacité réelle à désactiver le système.
• Qui valide : la direction générale ou le comité qui porte le risque, avec le responsable du contrôle interne.
• Risque à surveiller : une supervision qui devient un simple tampon, où l'humain valide sans examiner, faute de temps ou d'information.

Dette technique#

La dette technique est le coût futur créé par des choix rapides ou incomplets : code peu documenté, connexions fragiles, données mal nommées, absence de tests, dépendance à un prestataire unique. Comme une dette financière, elle n'est pas un problème en soi, mais elle devient coûteuse si elle n'est jamais remboursée et qu'elle s'accumule. Dans les projets d'IA, elle grandit vite, car les modèles, les prompts et les données évoluent en permanence et doivent être maintenus ensemble.

Intérêt pour le dirigeant. Une preuve de concept qui fonctionne peut masquer une dette importante. Le dirigeant doit demander ce qu'il faudra faire pour mettre le système en exploitation durable, qui le maintiendra et à quel coût de remise à niveau.

Exemple générique. Un outil est développé en urgence pour une équipe. Il fonctionne, mais les règles de traitement se trouvent dans le code d'une seule personne, sans documentation. Lorsque cette personne change de poste, la maintenance devient une opération de reconstruction.

Question de décision. Que coûtera la maintenance de ce système dans la durée, et qui sait le faire fonctionner ?

• Quoi vérifier : la documentation, les tests automatisés, la qualité des connexions et l'existence d'une équipe ou d'un prestataire identifié pour les mises à jour.
• Qui valide : le DSI et le responsable de l'exploitation.
• Risque à surveiller : une dépendance à une personne ou à un prestataire, et l'accumulation silencieuse de solutions provisoires qui deviennent permanentes.

Gouvernance#

La gouvernance répond à une question simple : qui décide quoi, sur quelle base, et qui répond en cas de problème. Les notions de cette partie fixent le cadre juridique européen, les données qui doivent être gérées comme un actif et les choix d'hébergement qui conditionnent le contrôle. Ce ne sont pas des sujets réservés aux juristes : ils engagent le conseil, le comité d'audit et chaque responsable de processus.

Gouvernance des données#

La gouvernance des données est l'ensemble des règles, des rôles et des processus qui définissent qui est responsable de quelle donnée, comment elle est définie, qui peut y accéder, comment elle est corrigée et comment elle est supprimée. Elle précise les propriétaires des données (la personne qui répond de leur exactitude et de leur usage), les garants de leur qualité et les règles de partage. Sans elle, un projet d'IA reprend des données contradictoires et reproduit leurs incohérences à grande échelle.

Intérêt pour le dirigeant. Une organisation qui n'a pas de gouvernance des données ne peut pas dire ce que son système sait réellement. Elle ne peut pas non plus sécuriser le projet, car les responsabilités restent floues dès qu'un incident survient.

Exemple générique. Un service commercial et un service financier utilisent des définitions différentes du même client. L'outil d'IA est alimenté par les deux, et ses analyses ne concordent pas avec les tableaux de bord habituels. La gouvernance tranche la définition de référence et désigne un propriétaire.

Question de décision. Pour chaque donnée utilisée par le système, savons-nous qui en répond et selon quelle définition ?

• Quoi vérifier : le registre des données, les propriétaires nommés, les définitions communes et les règles d'accès.
• Qui valide : le comité de gouvernance des données, avec le DAF pour les données financières.
• Risque à surveiller : des données utilisées par l'IA sans propriétaire, qui dérivent sans que personne ne le voie.

Le tableau suivant résume la répartition habituelle des validations dans un projet d'IA. Il doit être adapté à la taille et à l'organisation de chaque entreprise.

RGPD#

Le RGPD (règlement général sur la protection des données) est le texte européen qui encadre le traitement des données personnelles. Il repose sur des principes comme la licéité, la finalité, la minimisation des données, la limitation de conservation, la sécurité et la transparence envers les personnes concernées. Il donne à celles-ci des droits, notamment d'accès, de rectification et d'opposition, et impose de documenter les traitements. Ses exigences s'appliquent pleinement aux projets d'IA dès qu'ils traitent des données de personnes.

Intérêt pour le dirigeant. Le RGPD n'interdit pas l'IA, mais il oblige à savoir ce que l'on fait des données personnelles et pourquoi. Pour un dirigeant, c'est une question de responsabilité juridique, de confiance des clients et de capacité à répondre à une demande émanant d'une personne concernée.

Exemple générique. Un cabinet souhaite utiliser les courriels de ses clients pour entraîner un outil de réponse. Avant toute collecte, il doit définir la finalité, vérifier qu'elle est compatible avec celle pour laquelle les courriels ont été reçus, et informer les personnes concernées.

Question de décision. Chaque traitement qui implique des données personnelles est-il documenté, justifié et connu des personnes concernées ?

• Quoi vérifier : le registre des traitements, la base juridique et la finalité, les sous-traitants impliqués et les droits des personnes exerçables pour ce traitement.
• Qui valide : le DPO, avec le juriste pour l'interprétation (les obligations doivent être vérifiées avec un juriste).
• Risque à surveiller : un usage détourné d'une donnée collectée pour un autre objectif, ou un prestataire qui conserve les données au-delà de ce que le contrat prévoit.

AI Act#

L'AI Act est le règlement européen sur l'intelligence artificielle. Il organise les obligations selon une approche par niveau de risque : certaines pratiques sont interdites, les systèmes à risque élevé doivent respecter des exigences renforcées, et d'autres sont soumis à des obligations de transparence. Il met en avant des principes comme la supervision humaine, la traçabilité, la qualité des données et l'information des utilisateurs. Son application se fait par étapes, et ses obligations précises doivent être vérifiées avec un juriste pour chaque cas.

Intérêt pour le dirigeant. L'AI Act est une grille de lecture. Il aide à classer les projets selon leur niveau de risque avant de se demander comment les exploiter. Il oblige aussi à savoir quels systèmes utilisés par l'entreprise sont fournis par des tiers, et quelles obligations pèsent alors sur elle en tant qu'utilisatrice.

Exemple générique. Une entreprise utilise un outil de tri de candidatures fourni par un éditeur. Même si elle n'a pas développé cet outil, elle peut avoir des obligations en tant qu'utilisatrice, en particulier sur la supervision et l'information des personnes concernées.

Question de décision. Savons-nous, pour chaque système, sa catégorie de risque au sens de l'AI Act, et qui en porte les obligations ?

• Quoi vérifier : l'inventaire des systèmes utilisés ou développés, la catégorie de risque attribuée à chacun, le rôle de l'entreprise (fournisseur ou utilisateur) et les obligations associées, vérifiées avec un juriste.
• Qui valide : la direction juridique, avec le DPO et le responsable des systèmes d'information.
• Risque à surveiller : une classification faite à la légère, qui sous-estime un usage sensible, ou un système tiers dont les obligations ont été oubliées.

Système à haut risque#

Un système à haut risque, au sens de l'AI Act, est un système d'IA dont l'usage peut porter une atteinte importante à la sécurité, aux droits fondamentaux ou à l'accès à certains services, par exemple dans le recrutement, l'évaluation de la solvabilité ou certaines décisions administratives. Le texte prévoit pour ces systèmes des exigences renforcées : gestion des risques, qualité des données, documentation technique, traçabilité, supervision humaine et robustesse. La liste précise des cas concernés et les obligations applicables doivent être vérifiées avec un juriste.

Intérêt pour le dirigeant. Le statut de système à haut risque modifie le niveau de préparation attendu, le temps de conception et les responsabilités internes. Un dirigeant doit savoir détecter les usages qui pourraient entrer dans cette catégorie, même lorsqu'ils semblent anodins au départ.

Exemple générique. Un service utilise un système pour prioriser les dossiers de demande de prêt. Même si l'outil ne décide pas seul, son classement influence la décision humaine. Une analyse juridique est nécessaire pour savoir si ce type d'usage relève de la catégorie à haut risque.

Question de décision. Un de nos usages peut-il affecter l'accès à un service, à un emploi ou à une décision importante pour une personne, et qui l'a examiné ?

• Quoi vérifier : les finalités du système, son influence réelle sur la décision, les données utilisées et la présence d'un dossier de conformité.
• Qui valide : le juriste et le comité de direction, sur la base d'un avis documenté.
• Risque à surveiller : un usage présenté comme une simple aide qui devient, en pratique, la décision, sans que les exigences renforcées aient été examinées.

Hébergement souverain#

L'hébergement souverain désigne une organisation de l'infrastructure et des données qui permet à l'entreprise de garder la maîtrise de leur localisation, des personnes qui y accèdent et des lois auxquelles elles sont soumises. Il peut passer par un hébergement dans un territoire donné, par des clauses contractuelles encadrant l'accès, ou par des modèles exploitables dans l'infrastructure de l'entreprise ou d'un partenaire de confiance. La notion ne se réduit pas au lieu géographique : elle concerne aussi la dépendance à un prestataire et la capacité à reprendre la main.

Intérêt pour le dirigeant. Le choix d'hébergement engage la confidentialité, la conformité et la capacité à changer de fournisseur. C'est un arbitrage entre contrôle, performance et coût, qu'il faut trancher explicitement plutôt que subir.

Exemple générique. Une direction financière souhaite traiter des données de paie avec un outil d'IA. Elle compare une solution hébergée dans l'infrastructure de l'entreprise, plus contrôlée mais plus lourde à maintenir, et une solution externe dont elle vérifie les clauses contractuelles et l'exposition aux législations étrangères.

Question de décision. Où sont stockées et traitées nos données, qui peut y accéder, et comment pourrions-nous changer de fournisseur sans tout reconstruire ?

• Quoi vérifier : la localisation des données et des traitements, les accès des personnels du prestataire, les clauses de réversibilité et l'exposition à des législations extra-européennes.
• Qui valide : le DSI, le DPO et la direction juridique.
• Risque à surveiller : une dépendance technique et juridique à un acteur unique, et un accès à des données sensibles par des tiers non identifiés.

Mesure#

Un projet d'IA se juge à ce qu'il mesure. Sans méthode d'évaluation, les démonstrations convaincantes et les décisions de déploiement reposent sur des impressions. Les notions de cette partie décrivent comment établir une référence, comment comparer les résultats dans le temps et comment passer du test à l'usage réel, sans jamais fixer de seuils chiffrés qui dépendraient de chaque contexte.

Évaluation#

L'évaluation est la démarche qui consiste à mesurer la qualité d'un système selon des critères définis à l'avance : exactitude, complétude, cohérence, temps de réponse, respect des règles, satisfaction des utilisateurs. Elle compare les résultats du système à une référence, qui peut être une décision humaine validée ou la réponse d'un spécialiste. Une évaluation sérieuse précise la méthode de mesure, la population testée et ce qui est considéré comme une réussite. Elle doit être répétée, car la qualité change avec les données, les modèles et les usages.

Intérêt pour le dirigeant. L'évaluation permet de fonder une décision sur des mesures plutôt que sur une impression favorable. Il faut exiger un protocole écrit avant de voir les résultats, pour éviter qu'ils soient interprétés après coup.

Exemple générique. Une équipe évalue un outil de classement de factures en le comparant à un classement déjà validé par des comptables. Elle mesure séparément les erreurs sur les factures courantes et sur les cas inhabituels, puis décide de l'action à mener pour chaque type d'erreur.

Question de décision. Quelle méthode, quelle référence et quels critères avons-nous fixés avant de regarder les résultats ?

• Quoi vérifier : la définition des critères, la référence de comparaison, la représentativité de la population testée et la séparation entre données de réglage et données de test.
• Qui valide : le responsable métier pour la définition de la réussite, et une fonction indépendante pour la méthode.
• Risque à surveiller : des critères choisis après coup, qui favorisent le système évalué.

Jeu de test#

Un jeu de test est un ensemble de cas représentatifs, dont la bonne réponse est connue, réservé à la mesure de la qualité d'un système. Il doit être distinct des données utilisées pour l'entraîner ou le régler, sans quoi le résultat est artificiellement favorable. Un bon jeu de test couvre les cas courants, les cas rares, les situations ambiguës et les erreurs déjà observées. Il doit lui-même être maintenu, car un jeu ancien ne reflète plus l'activité réelle.

Intérêt pour le dirigeant. Le jeu de test est un actif. Il permet de comparer des versions, de repérer une éventuelle régression après une mise à jour et de démontrer ce qui a été testé. Un dirigeant doit savoir qui le constitue et s'il est accessible à l'équipe qui développe le système.

Exemple générique. Une équipe constitue un jeu de cas de contrats dont la bonne réponse a été établie par un juriste. Chaque nouvelle version du système passe ce jeu avant d'être déployée, et les échecs sont ajoutés au jeu.

Question de décision. Le jeu de test est-il indépendant du développement, à jour et assez exigeant pour révéler les vrais échecs ?

• Quoi vérifier : la séparation avec les données d'entraînement, la couverture des cas difficiles, la date de dernière mise à jour et la traçabilité de chaque bonne réponse.
• Qui valide : le responsable métier, qui connaît les bonnes réponses, avec le contrôle interne.
• Risque à surveiller : un jeu de test trop facile ou trop proche des données d'entraînement, qui fait paraître le système meilleur qu'il n'est.

Dérive#

La dérive désigne l'évolution progressive du comportement d'un système, ou de la qualité de ses résultats, parce que les données ou le contexte changent. On distingue souvent la dérive des données (les entrées ne ressemblent plus à celles d'origine), la dérive du concept (la relation entre les entrées et les bonnes réponses change) et la dérive de performance (les résultats se dégradent). Une dérive peut être lente et invisible si personne ne mesure les résultats dans le temps.

Intérêt pour le dirigeant. Un système validé à un moment donné ne reste pas validé indéfiniment. Il faut savoir qui surveille la qualité après la mise en production, à quelle fréquence et selon quels indicateurs, car la dérive est précisément ce qui n'apparaît pas lors d'une démonstration.

Exemple générique. Un outil fonctionnait bien sur les dossiers habituels. Une évolution de l'activité fait apparaître de nouveaux types d'opérations. La qualité baisse sans bruit, jusqu'à ce qu'un contrôle manuel révèle des erreurs récurrentes.

Question de décision. Quels indicateurs surveillons-nous en continu, et qui réagit lorsqu'ils s'écartent de la référence ?

• Quoi vérifier : les indicateurs de qualité suivis, la comparaison régulière avec le jeu de test, les alertes configurées et le plan de réentraînement ou de retrait.
• Qui valide : le propriétaire du système, avec le contrôle interne.
• Risque à surveiller : une dégradation silencieuse, d'autant plus dangereuse qu'elle paraît normale aux utilisateurs.

Latence#

La latence est le temps écoulé entre une demande et la réponse qui en découle. Pour un système d'IA, elle dépend de la taille du modèle, de la longueur des entrées et des sorties, de la charge du service et de l'éloignement géographique du traitement. Une latence élevée n'est pas un défaut en soi. Elle devient un problème lorsqu'elle empêche l'usage prévu, par exemple lorsqu'un utilisateur attend une réponse au milieu d'un échange, ou qu'un processus automatisé prend du retard.

Intérêt pour le dirigeant. La latence influence l'adoption réelle d'un outil. La rapidité observée lors d'une démonstration ne prédit pas celle de la production, qui dépend de la charge, de l'intégration et des volumes effectivement traités.

Exemple générique. Un outil de réponse aux questions internes est rapide lors des tests. En production, aux heures de forte activité, les utilisateurs abandonnent leur demande, car l'attente interrompt leur travail. L'équipe décide alors de n'utiliser l'outil que pour les tâches où une attente est acceptable.

Question de décision. Le temps de réponse mesuré en conditions réelles est-il compatible avec le moment où l'utilisateur en a besoin ?

• Quoi vérifier : la mesure du temps de réponse sur des charges représentatives, la distinction entre le temps de première réponse et le temps de réponse complète, et le comportement du système lors d'un pic.
• Qui valide : le responsable de la production informatique, avec le métier qui utilise l'outil.
• Risque à surveiller : une expérience utilisateur dégradée qui pousse à contourner l'outil, et donc à sortir du cadre validé.

Preuve de concept#

Une preuve de concept (en anglais proof of concept, souvent abrégée PoC) est un test limité, conçu pour vérifier qu'un cas d'usage est techniquement possible et qu'il produit un résultat exploitable sur un périmètre réduit. Elle répond à la question « est-ce faisable ? », et non à la question « est-ce robuste et rentable ? ». Une preuve de concept bien conduite définit à l'avance ses critères de réussite et ses limites. Sans cela, elle devient une démonstration impressionnante qui ne prouve rien.

Intérêt pour le dirigeant. La preuve de concept est l'outil naturel du dirigeant avant d'investir largement. Elle doit être dimensionnée pour apporter une réponse à une décision précise, et non pour produire une vitrine. Le risque est de la confondre avec un projet prêt à être déployé.

Exemple générique. Une équipe teste la classification de demandes entrantes sur un périmètre restreint. La preuve établit que le système comprend l'essentiel des demandes, mais révèle que les demandes rédigées dans une autre langue ne sont pas traitées correctement, ce qui oriente la suite du projet.

Question de décision. La preuve de concept répond-elle à une question de décision, avec des critères écrits, et prévoit-elle ce qui se passera après ?

• Quoi vérifier : la question posée, les critères de réussite et d'échec, les données utilisées et leur légitimité juridique, et le plan de suite en cas de succès ou d'échec.
• Qui valide : le sponsor métier et le comité qui arbitre les investissements.
• Risque à surveiller : une preuve de concept qui s'étend sans décision formelle, ou dont les résultats sont présentés comme acquis pour un déploiement.

Passage à l'échelle#

Le passage à l'échelle est l'extension d'un système validé à un périmètre plus large : davantage d'utilisateurs, de données, de processus, de sites ou de types de demandes. Il ne consiste pas à multiplier les licences. Il exige d'adapter l'architecture, la supervision, la formation, les droits d'accès, la maintenance et le contrôle des coûts d'usage. Beaucoup de projets réussissent leur démonstration puis peinent à cette étape, faute d'avoir anticipé ces exigences.

Intérêt pour le dirigeant. Le passage à l'échelle est la phase où le projet devient une dépendance d'organisation. Il faut décider qui en est propriétaire, comment les équipes sont formées et quel cadre de contrôle s'applique à mesure que l'usage se généralise.

Exemple générique. Un outil de synthèse, validé dans une équipe, doit être déployé dans plusieurs services. Chacun a des documents différents, des règles propres et des exigences de confidentialité. Le passage à l'échelle impose un inventaire des usages et des contrôles adaptés à chacun.

Question de décision. Ce qui a fonctionné sur un périmètre restreint tiendra-t-il lorsque l'usage se généralisera, et qui en assumera la charge ?

• Quoi vérifier : la capacité technique, les coûts d'usage projetés selon plusieurs scénarios, la formation des nouveaux utilisateurs, les droits d'accès et la procédure de gestion des incidents.
• Qui valide : la direction des systèmes d'information, le propriétaire métier et le comité de gouvernance.
• Risque à surveiller : une généralisation qui dépasse le cadre validé, avec des données ou des usages qui n'avaient pas été prévus au départ.

Comment utiliser ce glossaire en comité#

Un glossaire n'a de valeur que s'il modifie la discussion. Les points suivants proposent une méthode simple pour s'en servir lors d'une revue de projet ou de la présentation d'un prestataire.

• Commencez par la décision, pas par la technologie. Formulez la décision à prendre en une phrase : investir, poursuivre, arrêter ou étendre. Les notions utiles sont celles qui éclairent cette décision, les autres peuvent attendre.
• Demandez les preuves dans un ordre logique. D'abord les données (origine, droits, représentativité), puis la méthode d'évaluation, puis les mécanismes de supervision et de traçabilité, enfin les coûts d'exploitation et les conditions de sortie. Cet ordre aide à ne pas discuter d'une performance dont les conditions de mesure sont inconnues.
• Nommez un responsable pour chaque risque. Chaque question de décision de ce glossaire indique le type de validateur attendu. Pendant la réunion, attribuez le sujet à une personne précise et notez la date de validation attendue.
• Tenez un registre des décisions. Consignez les usages acceptés, les usages refusés et les conditions posées. Ce registre sert de base à la gouvernance et aux revues ultérieures, et il limite le risque de reprendre les mêmes débats à chaque changement d'équipe.
• Reprenez les fiches à chaque jalon. Une notion qui n'était pas centrale au lancement peut devenir déterminante au moment du passage à l'échelle. Relisez les fiches concernées à chaque étape.

Gardez enfin en tête qu'un prestataire peut être à la fois honnête et incomplet. Une présentation claire sur la performance ne dispense pas de demander des preuves sur les données, sur la supervision et sur les conditions de sortie du contrat.

Glossaire#

Ce récapitulatif reprend les notions des fiches, avec une définition en une ligne et la partie du texte où elles sont développées. Il est suivi de termes annexes, fréquemment employés en comité.

Termes annexes :

• Plongement vectoriel (embedding). Représentation d'un texte sous forme de série de nombres, qui permet de comparer des sens. C'est une brique courante de la recherche dans une base de connaissances.
• Tokenisation. Découpage d'un texte en jetons avant traitement. Un même texte peut être découpé différemment selon le modèle utilisé.
• Température. Paramètre qui règle la part d'aléatoire dans les réponses. Une valeur plus basse rend les réponses plus stables, sans les rendre pour autant vraies.
• Responsable de traitement et sous-traitant. Le premier détermine la finalité et les moyens d'un traitement de données personnelles, le second le réalise pour son compte. Ce rôle conditionne les obligations de chacun.
• Journal d'audit (log). Enregistrement horodaté des actions d'un système ou d'un utilisateur. Il doit être protégé, car il peut lui-même contenir des données sensibles.
• Vérité terrain (ground truth). Bonne réponse établie par une source fiable et utilisée comme référence lors de l'évaluation. La qualité de cette référence limite celle de l'évaluation.
• Mode ombre (shadow mode). Exploitation d'un système en parallèle d'un processus existant, sans effet sur les décisions, afin de comparer ses résultats.
• Retour utilisateur (feedback). Signalement par l'utilisateur qu'une réponse est correcte ou fausse. Il sert à améliorer le système, à condition d'être trié et qualifié.
• Intégration. Connexion du système aux outils existants de l'entreprise. C'est souvent là que se concentrent les risques de sécurité et les coûts cachés.
• Cloud. Infrastructure informatique louée à distance, sur laquelle les données et les traitements sont hébergés chez un prestataire. Son usage pose les questions de localisation et de contrôle.
• Modèle ouvert et modèle propriétaire. Le premier voit son fonctionnement publié et peut être installé par l'entreprise elle-même, le second est exploité par un éditeur qui en garde le contrôle. Ce choix conditionne la souveraineté et le degré de dépendance.

Checklist à imprimer#

Imprimez cette liste et cochez-la lors de chaque revue de projet. Elle ne remplace ni l'avis d'un juriste ni celui d'un expert en sécurité.

Avant de lancer#

• La décision à prendre est formulée en une phrase, avec son responsable nommé.
• Le cas d'usage dispose d'un critère de réussite écrit avant tout test.
• L'origine des données utilisées est connue, et leurs droits d'usage ont été vérifiés.
• Les données personnelles impliquées sont listées, avec leur finalité et leur base juridique.
• Le système a été classé au regard de l'AI Act, avec un avis juridique documenté.
• La localisation des données et des traitements a été choisie explicitement.

Pendant le test#

• Le jeu de test est séparé des données d'entraînement et couvre les cas difficiles.
• La méthode d'évaluation a été fixée avant de regarder les résultats.
• Les résultats sont découpés par sous-populations ou par types de cas.
• Les erreurs sont classées, et leur gravité est évaluée par le métier.
• Les réponses sans source ou les questions sans réponse dans les documents ont été testées.
• Le système a été confronté à des données dégradées ou inattendues.

Avant la mise en production#

• La supervision humaine est nommée, avec son pouvoir d'arrêt et ses seuils d'escalade.
• Les journaux de traçabilité sont actifs et protégés.
• Les explications fournies aux utilisateurs et aux personnes concernées ont été vérifiées.
• Les droits d'accès sont limités au besoin réel, y compris pour les actions automatiques.
• La documentation permet à une autre équipe de reprendre la maintenance.
• Les interdictions d'usage et les cas à ne jamais confier au système sont écrits et diffusés.

En exploitation#

• Des indicateurs de qualité sont suivis dans le temps, avec une fréquence de revue définie.
• La dérive est surveillée, et le seuil d'alerte est connu du propriétaire du système.
• Le coût d'usage est suivi au regard des volumes réels, et non des hypothèses initiales.
• Les incidents sont consignés, analysés et transmis au comité de gouvernance.
• Les bases de connaissances et les prompts validés sont mis à jour et versionnés.
• Une procédure de retrait du système est documentée et testée à intervalles réguliers.

Questions fréquentes#

Faut-il être ingénieur pour décider d'un projet d'IA ?#

Non. Il faut comprendre les notions de données, de risque et de contrôle, et savoir demander des preuves. Les choix techniques restent confiés à des spécialistes, mais le cadrage des usages et leur validation reviennent au métier et à la direction.

Un prestataire qui annonce un résultat rapide et fiable doit-il inspirer confiance ?#

Pas à lui seul. Une annonce de résultat sans méthode d'évaluation, sans jeu de test ni description des limites n'apporte pas d'information exploitable. Demandez toujours comment la performance est mesurée et dans quelles conditions elle a été obtenue.

Quelle différence entre un copilote et un agent IA ?#

Le copilote accompagne une personne qui garde la décision et l'action. L'agent IA planifie et exécute des étapes, avec des outils et des droits d'accès. Plus l'agent peut agir seul, plus les contrôles, les journaux et les limites d'autorisation doivent être précis.

Le RGPD interdit-il d'utiliser des données clients avec un outil d'IA ?#

Il n'interdit pas cet usage, mais il encadre étroitement la finalité, la base juridique, l'information des personnes et le rôle des sous-traitants. Un traitement doit être documenté avant d'être lancé. Ces règles doivent être vérifiées avec le DPO et un juriste pour chaque cas.

Faut-il attendre que la réglementation soit stabilisée avant de lancer un projet ?#

Il est plus prudent de classer les usages selon leur niveau de risque et de commencer par ceux qui présentent peu d'enjeux pour les personnes. Les obligations précises doivent être vérifiées avec un juriste, et l'inventaire des systèmes utilisés constitue une base utile dans tous les cas.

Conclusion#

Ce glossaire ne rend pas l'intelligence artificielle simple, et il ne prétend pas le faire. Il montre plutôt que les notions qui comptent pour un dirigeant ne sont pas toujours les plus techniques. La qualité des données d'entraînement, la traçabilité d'une décision, la supervision humaine ou les conditions de sortie d'un contrat pèsent souvent davantage que la sophistication du modèle. Le vocabulaire sert à formuler des questions précises, à identifier qui doit répondre et à mettre les risques en discussion avant qu'ils ne se traduisent en incidents.

Il faut aussi retenir que ces notions se recouvrent. Une base de connaissances mal tenue nourrit des réponses fausses malgré une bonne fenêtre de lecture, une donnée personnelle mal pseudonymisée complique la conformité, et une évaluation sans jeu de test indépendant ne dit rien de la dérive. Les équipes qui avancent avec méthode tendent à lire ces notions comme un système cohérent, et non comme une liste à mémoriser.

Enfin, ce texte ne remplace ni un juriste, ni un auditeur, ni un expert en sécurité. Il permet en revanche d'échanger avec eux dans un langage commun, et de savoir ce qu'il faut leur demander, à quel moment et dans quel ordre.