Méthodologie d'une analyse technique IA
Une analyse technique d'un système d'intelligence artificielle part d'une question précise et s'arrête à ce que les éléments disponibles permettent d'établir. Entre les deux, chaque opération est décrite de façon à pouvoir être discutée et refaite.
L'analyse suit une chaîne : question, preuve, test, observation, limite, conclusion. Elle commence par délimiter la question technique posée, identifie le système en cause et ses composants (interface, instructions, données, modèle, outils, validation humaine), recense les versions et les traces disponibles, puis procède si possible à une reproduction contrôlée. Chaque constat est classé : fait établi par une pièce, observation faite lors d'un test, ou hypothèse. Un système fondé sur un modèle de langage est souvent probabiliste : une réponse passée peut ne pas se reproduire à l'identique, et cette limite est écrite, pas contournée. Les conclusions restent dans la compétence technique ; la qualification juridique appartient au juge.
Le principe : de la question à la conclusion
Cette page décrit l'analyse technique elle-même. Le cadre dans lequel elle s'inscrit lorsqu'un spécialiste intervient comme sapiteur — acceptation, autorisations, lettre de mission, remise de l'avis — est décrit sur la page méthodologie d'une intervention de sapiteur.
La méthode tient en six maillons. Aucun ne peut être sauté : une conclusion qui ne s'appuie pas sur une observation, ou une observation qui ne renvoie à aucun élément identifié, ne résiste pas à la discussion.
Question
Ce que l'on cherche à établir, formulé en termes techniques vérifiables.
Preuve
Les éléments disponibles : journaux, configurations, sorties conservées, documentation, déclarations.
Test
L'opération menée pour confronter la question aux éléments : lecture, comparaison, reproduction.
Observation
Ce qui a été constaté, avec les conditions exactes du constat.
Limite
Ce que l'observation ne permet pas d'affirmer, et pourquoi.
Conclusion
La réponse à la question, bornée par ses limites et restreinte à la compétence technique.
Les quatorze étapes d'une analyse
L'ordre ci-dessous est celui d'une analyse complète. Selon la question posée, certaines étapes sont brèves ; aucune n'est omise sans que la raison en soit écrite.
Définir exactement la question technique
« L'IA s'est-elle trompée ? » n'est pas une question technique. « La réponse produite le 12 mars reposait-elle sur le document X présent dans la base documentaire à cette date ? » en est une. La reformulation est soumise à celui qui pose la question avant tout travail.
Délimiter le périmètre
Quels composants, quelle période, quelles versions. Ce qui est hors périmètre est écrit, pour que personne ne lise dans la conclusion une réponse qu'elle ne donne pas.
Identifier le système
Produit commercial utilisé tel quel, produit configuré, développement sur mesure appelant un modèle par API, ou chaîne d'automatisation mêlant plusieurs outils. La réponse conditionne les éléments que l'on peut espérer obtenir.
Cartographier les composants
Utilisateur, interface, instructions système, requête, données injectées, modèle, outils appelés, résultat, validation humaine. La carte montre où une trace peut exister et où elle manque.
Identifier les versions
Version du modèle, de l'application, de la configuration et de la base documentaire à la date des faits. Un fournisseur peut faire évoluer ou retirer un modèle ; un nom commercial ne désigne pas toujours le même modèle d'un mois à l'autre.
Inventorier les données disponibles
Ce qui existe, ce qui a existé et a été effacé, ce qui n'a jamais été conservé. L'absence de trace est un constat en soi.
Collecter la configuration
Paramètres de génération, réglages de l'application, connecteurs et droits d'accès, avec leur date. Chaque élément reçu est identifié et son empreinte numérique relevée, pour qu'on puisse vérifier plus tard qu'il n'a pas changé.
Identifier les prompts et instructions
Instructions système, modèles de requête, requêtes effectivement envoyées, lorsqu'elles sont disponibles. Elles expliquent souvent une sortie mieux que le modèle lui-même.
Analyser les journaux
Horodatages, identifiants de requête, appels d'outils, erreurs. Leur complétude est vérifiée avant leur contenu : un journal lacunaire peut conduire à une chronologie fausse. Les fournisseurs d'API ne conservent en général les requêtes que pour une durée limitée, souvent de l'ordre de trente jours, et parfois pas du tout ; les journaux de l'organisation qui exploite le système sont souvent la seule source exploitable. L'ANSSI recommande de journaliser les requêtes, les traitements intermédiaires, les appels d'outils et les réponses, afin de pouvoir reconstituer entièrement un événement.
Reproduire de façon contrôlée, lorsque c'est possible
Rejouer la situation avec la même configuration, en faisant varier un paramètre à la fois et en répétant chaque essai. Les conditions de chaque essai sont consignées. Voir plus bas les limites de la reproduction.
Distinguer fait, observation et hypothèse
Chaque constat reçoit son statut, selon la grille ci-dessous. Le statut suit le constat jusque dans la conclusion.
Soumettre les opérations à la discussion
Les tests sont décrits de manière à pouvoir être contestés et refaits. Les éléments qu'une partie avance sont examinés avec la même méthode que les autres.
Documenter les limites
Ce qui n'a pas pu être vérifié, faute d'élément, d'accès ou de possibilité technique. Une limite écrite n'affaiblit pas un avis ; une limite passée sous silence le fragilise.
Conclure dans la compétence technique
La conclusion répond à la question posée, et seulement à elle. Elle ne dit pas qui est responsable, ni si une pièce est recevable.
Distinguer fait, observation et hypothèse
Un même rapport mêle des énoncés de nature différente. Les confondre est la faute la plus courante des analyses de systèmes d'IA : une hypothèse plausible finit par être lue comme un fait.
| Statut | Définition | Exemple |
|---|---|---|
| Fait établi | Attesté par un élément identifié et vérifiable. | Le journal horodaté montre un appel au modèle le 12 mars à 10 h 04. |
| Observation | Constaté lors d'un test dont les conditions sont décrites. | Sur vingt essais avec la configuration fournie, dix-sept réponses citent le document X. |
| Hypothèse | Explication compatible avec les éléments, non démontrée. | Le document X a pu être ajouté à la base après le 12 mars. |
| Non déterminable | Aucun élément disponible ne permet de trancher. | La requête exacte du 12 mars n'a pas été conservée. |
Peut-on reproduire exactement une réponse d'IA ?
Souvent, non. Un même modèle, interrogé deux fois avec la même requête, peut produire deux réponses différentes, et les fournisseurs l'indiquent eux-mêmes dans leur documentation. Un modèle de langage choisit chaque élément de sa réponse parmi plusieurs possibilités pondérées ; le paramètre de température règle la part de hasard dans ce choix. Même réglée à zéro, la sortie d'un modèle accessible par API n'est pas garantie identique d'un appel à l'autre, notamment parce que le résultat d'un calcul peut dépendre de la charge des serveurs qui le traitent. Sur certains modèles récents, ce réglage n'est d'ailleurs plus proposé. Les mécanismes de reproductibilité offerts par certains fournisseurs sont décrits comme des efforts, pas comme des garanties.
S'y ajoute le temps : un modèle peut être mis à jour ou retiré, une base documentaire modifiée, une instruction système réécrite. Les fournisseurs retirent régulièrement leurs anciens modèles, avec un préavis ; une fois un modèle retiré, rejouer une requête à l'identique chez ce fournisseur peut devenir impossible, même si un hébergeur partenaire le propose parfois encore quelque temps. Rejouer une requête des mois plus tard, c'est souvent interroger un autre système.
L'analyse porte donc moins sur la réobtention d'une sortie identique que sur la reconstitution de ce qui a été envoyé au modèle, de ce qu'il a renvoyé et de ce que le système en a fait. La question se pose concrètement dans les litiges sur un assistant qui a donné une information erronée ou sur des références inventées par une IA.
Ce que l'on peut faire, en revanche :
- répéter un essai un nombre suffisant de fois et décrire la distribution des réponses plutôt qu'une réponse isolée ;
- comparer le comportement du système selon qu'un élément est présent ou absent (un document, une instruction) ;
- établir, à partir des versions et des journaux, si le système interrogé aujourd'hui est bien celui des faits ;
- consigner chaque paramètre de chaque essai, pour qu'un autre technicien obtienne des résultats comparables.
Traçabilité des opérations et contradictoire
En procédure civile, le juge doit faire observer et observer lui-même le principe de la contradiction, et l'expert accomplit sa mission avec conscience, objectivité et impartialité. Appliqué à l'analyse d'un système d'IA, cela se traduit par des pratiques simples :
- chaque élément reçu est identifié, daté et accompagné de son empreinte numérique ;
- chaque test est décrit : système, version, paramètres, données, nombre d'essais, date ;
- les sorties obtenues sont conservées telles quelles, y compris celles qui contredisent l'hypothèse de travail ;
- les éléments et scripts utilisés sont communicables, pour que les parties et leurs conseils techniques puissent les discuter.
Lorsque le spécialiste intervient comme sapiteur en matière civile, son avis est joint au rapport de l'expert, qui conserve la maîtrise de sa mission. Le guide du CNCEJ consacré au sapiteur recommande que cet avis soit écrit, sauf exception, et que les échanges avec les parties passent par l'expert. La forme de l'avis doit donc permettre à l'expert, puis aux parties, d'en suivre le raisonnement sans l'aide de son auteur.
Ce que l'analyse technique ne conclut pas
- Elle ne dit pas qui est responsable. Elle peut établir quel composant a produit quel effet, dans quelles conditions.
- Elle ne dit pas qu'une pièce est recevable. Elle peut décrire comment un élément a été produit et s'il a pu être modifié.
- Elle n'affirme pas avec certitude qu'un contenu a été généré par une IA lorsque les outils disponibles ne le permettent pas. Voir ce que vaut un score de détecteur.
- Elle ne sort pas de la spécialité du technicien. Une question de sécurité informatique, de criminalistique numérique ou de mathématiques des modèles relève d'un autre spécialiste.
Sources et références
- Code de procédure civile, article 16.
- Code de procédure civile, article 237.
- Code de procédure civile, article 238.
- Code de procédure civile, article 278.
- Code de procédure civile, article 282.
- Le Sapiteur, édition 2024.
- How to make your completions outputs consistent with the new seed parameter.
- Horace He et Thinking Machines Lab, Defeating Nondeterminism in LLM Inference, billet de recherche, non évalué par des pairs.
- Glossary, entrées « Temperature » et « RAG ».
- Model deprecations, cycle de vie des modèles et paramètres dépréciés.
- Deprecations.
- Data controls in the OpenAI platform.
- API and data retention.
- Recommandations de sécurité pour un système d'IA générative (ANSSI-PA-102), recommandation R29, p. 25.
Rédaction : Denis Atlan Publié le Méthode éditoriale et corrections