L’IA a résumé l’appel d’offres. A-t-elle repéré la clause qui vous engage ?

01Commencez par un dossier que votre équipe connaît

Une démonstration peut produire en quelques minutes une synthèse propre, un tableau convaincant ou une première trame de réponse. Ce résultat ne montre pas si l’équipe saura repérer une erreur, vérifier les sources et reprendre le dossier à temps. Le vrai point de départ est moins spectaculaire : peut-elle nommer le dossier testé, le besoin métier, les personnes responsables, les données autorisées, les erreurs inacceptables et la manière de reprendre le travail si le système échoue ?

Le feu vert initial ne porte donc pas sur une promesse générale d’efficacité. Il autorise un essai borné, dans un contexte connu, avec des preuves examinables. Une entreprise peut juger l’idée pertinente et refuser néanmoins de lancer le pilote, parce qu’un responsable manque, qu’une catégorie de données reste incertaine ou que le traitement manuel ne peut pas être repris dans les délais. Différer l’essai laisse le temps de réunir les conditions qui manquent.

Le protocole doit rendre les désaccords visibles avant le premier essai. Le sponsor peut accepter le budget sans connaître les défauts métier. Le responsable opérationnel peut vouloir gagner du temps sans pouvoir définir ce qu’est une sortie exploitable. Les fonctions de sécurité peuvent approuver un environnement pour certaines données, mais pas pour toutes les pièces d’un appel d’offres. Un test lancé sur ces ambiguïtés produit un résultat séduisant dont personne ne sait exactement ce qu’il autorise.

La décision attendue est précise : lancer, différer ou refuser un pilote sur un type de dossier, pour une équipe et une durée définis. Son objet reste le feu vert initial. Le choix de l’architecture, le périmètre documentaire d’une future industrialisation et l’évaluation d’un rendement général relèvent d’autres décisions. À ce stade, chaque condition doit être vérifiable, placée sous la responsabilité d’une personne habilitée et appuyée par une preuve qui résiste à l’impression laissée par la démonstration.

Le corpus d’essai doit représenter le travail qui engage réellement l’entreprise. Les documents de consultation servent à comprendre le marché, à décider de candidater et à préparer la réponse. Ils associent règles de consultation, critères, délais, formats, clauses et éléments financiers. Tester seulement un document court et propre revient à supprimer du test les variations qui déterminent justement la décision et la charge de préparation.^[2]

Un dossier réel n’est pas nécessairement le dossier le plus volumineux ni le plus récent. Il est réel parce qu’il possède une histoire opérationnelle vérifiable : une équipe l’a reçu, des questions ont été soulevées, des pièces ont pesé sur la décision et certaines informations ont exigé une interprétation. Le pilote peut employer un dossier clos ou une copie préparée pour le test, sous réserve que son statut et ses transformations soient consignés.

Le corpus initial doit conserver les relations entre les pièces. Une date repérée dans un règlement peut modifier la lecture d’un calendrier. Une exigence technique peut dépendre d’une annexe. Une condition financière peut contredire une hypothèse tirée d’un autre document. Si les fichiers sont isolés de leur contexte, le pilote mesure une aptitude à résumer des fragments, pas la capacité à soutenir une qualification cohérente du dossier.

La composition du corpus répond à une question de décision : les éléments capables de modifier la compréhension du marché sont-ils présents ? Les pièces de candidature et celles de l’offre n’ont pas la même fonction. Les premières établissent notamment l’aptitude et les capacités du candidat, tandis que les secondes matérialisent la réponse technique et financière attendue.^[3][4] Cette distinction aide à repérer une omission sans transformer le pilote en cartographie définitive de tous les documents possibles.

La provenance doit rester lisible. Pour chaque dossier retenu, le protocole consigne la date de réception, la version, l’état de clôture, les pièces retirées ou remplacées et la raison de toute anonymisation. Une copie nettoyée peut être utile, mais elle ne doit pas être présentée comme intacte. Sinon, une amélioration due au nettoyage du corpus sera attribuée à tort au système testé.

Le choix des dossiers doit aussi éviter le biais du succès connu. Une équipe qui sélectionne uniquement les consultations qu’elle a bien maîtrisées fournit au pilote des exemples dont les ambiguïtés ont déjà été résolues. Il faut inclure au moins un dossier ayant demandé des vérifications, un autre comportant une information difficile à retrouver et un cas où l’absence d’un élément a compté dans l’analyse. Le but est de représenter fidèlement le travail, y compris ses épisodes les moins confortables.

L’annexe qui peut changer votre réponse

Une pièce est structurante lorsque son absence, sa mauvaise lecture ou sa mauvaise version peut modifier la décision initiale ou la préparation attendue. Ce statut ne dépend pas de son volume. Une annexe d’une page peut fixer une condition éliminatoire ; un document beaucoup plus long peut apporter seulement du contexte. Le responsable métier doit donc expliquer pourquoi chaque famille de pièces figure dans le corpus et quel risque sa présence permet d’éprouver.

La revue du corpus se fait avant le chargement. Elle vérifie que les documents s’ouvrent, que les versions sont identifiables, que les renvois utiles sont présents et que les pièces manquantes sont volontairement absentes ou réellement indisponibles. Ce dernier point compte : une information absente doit parfois conduire à déclarer une limite, pas à fabriquer une réponse probable.

Le dossier témoin doit conserver une lecture humaine de référence. Cette référence ne prétend pas être parfaite ; elle rassemble les informations que des professionnels ont effectivement jugées importantes, les hésitations rencontrées et les vérifications réalisées. Elle permettra ensuite de distinguer trois situations : information correctement retrouvée, information mal interprétée et information non repérée. Sans ce témoin, toute synthèse plausible risque d’être évaluée sur sa seule fluidité.

Le lot de documents reste inchangé pendant toute la comparaison. Ajouter une pièce après un premier échec peut être nécessaire pour comprendre le défaut, mais cette modification ouvre une nouvelle séquence d’essai. Elle ne doit pas effacer le résultat précédent. Le journal du pilote sépare ainsi les corrections apportées au corpus des variations propres au système.

02Limitez le pilote à une tâche dont le résultat peut être vérifié

Un pilote utile répond à un besoin concret et indique les usages autorisés comme les usages interdits. La CNIL recommande de partir du besoin, d’associer les parties prenantes et de définir les conditions d’utilisation d’un système d’IA générative. Elle demande également que les risques, les données et la vérification humaine soient envisagés dans le contexte réel de l’usage.^[16][6] Un intitulé tel que « aider aux appels d’offres » reste donc trop large pour autoriser un essai.

Le cas d’usage doit nommer une action observable. Il peut porter, par exemple, sur la préparation d’une synthèse destinée au responsable métier à partir d’un type de consultation défini. Cette formulation précise qui reçoit la sortie, à quel moment du processus et pour quelle utilisation. Elle ne suppose ni que la synthèse soit exacte par nature, ni qu’elle puisse être transmise sans contrôle.

Fixer une date de fin oblige à décider si l’essai doit continuer. Elle fixe la période pendant laquelle les personnes responsables sont disponibles, les dossiers restent comparables et les écarts peuvent être examinés. Une expérience sans date de fin tend à devenir un usage toléré avant que ses conditions aient été validées. Le pilote doit s’arrêter à son échéance, sauf décision explicite de poursuivre sous un nouveau cadre.

La population autorisée doit être identifiable. Une équipe nommée apprend à reconnaître les limites du test, applique les mêmes consignes et sait à qui signaler un écart. Ouvrir l’accès à toute l’entreprise pendant l’expérimentation introduit des usages, des documents et des attentes qui n’appartiennent plus au protocole. Le résultat devient alors impossible à attribuer au cas initial.

La sortie attendue doit aussi être bornée. Une synthèse de qualification, une liste de points à vérifier et une première structure de travail n’ont pas le même statut. Les règles applicables à la préparation d’une candidature, à l’offre et à sa remise montrent que plusieurs objets distincts coexistent dans le processus.^[3][4][14] Le pilote n’a pas besoin de les couvrir tous pour être pertinent.

Un cadrage externe peut être utile lorsque le besoin reste formulé par une ambition générale ou lorsque les usages déjà pratiqués ne sont pas connus. Un audit de cadrage des usages IA peut alors remettre le besoin, les responsabilités, les données et les exclusions dans un même support de décision. Cette étape ne préjuge pas du choix de la solution qui sera éventuellement testée.

Chacun doit savoir ce qui est testé

Le périmètre doit être formulé sans ambiguïté. Il précise le travail concerné, les personnes autorisées, la durée de l’essai et la nature de la production attendue. S’il permet à deux responsables d’imaginer des usages différents, le pilote n’est pas prêt.

Les exclusions doivent être aussi nettes que l’usage autorisé. Une consigne générale de prudence ne permet pas de reconnaître un dépassement. Leur formulation dépend des données, des acteurs et du mode de travail ; elle relève donc du cadrage propre à l’entreprise, pas d’un modèle universel.

La question décisive reste celle du bénéfice attendu pour une décision réelle. « Gagner du temps » ne suffit pas si l’on ignore sur quelle tâche, pour qui et sous quel contrôle. Les repères généraux d’adoption de l’IA dans les petites et moyennes entreprises invitent eux aussi à relier l’expérimentation à une situation d’entreprise plutôt qu’à la seule disponibilité d’une technologie.^[5]

03Ce que la synthèse doit contenir se décide avant le test

Le responsable métier définit ce que la sortie doit contenir avant d’en voir une première version. Cette antériorité évite un biais courant : une synthèse bien rédigée conduit l’équipe à reconstruire ses attentes autour de ce qu’elle reçoit. Le retour d’expérience sectoriel consacré au test de l’IA pour analyser des appels d’offres souligne l’implication du référent métier, la nécessité de tests reproductibles et le maintien du contrôle humain.^[12]

Définir la sortie ne consiste pas à écrire une consigne technique. Le métier décrit les informations utiles à sa décision, leur ordre éventuel, les distinctions qui doivent rester visibles et les erreurs qui rendraient le document inexploitable. Il précise aussi ce qui doit être déclaré comme non retrouvé. Cette dernière règle empêche une formulation plausible de masquer une absence dans les pièces.

Le responsable métier fournit le vocabulaire de référence. Un même terme peut avoir une portée particulière dans une activité, une entreprise ou un type de consultation. Sans cette précision, les testeurs risquent d’accepter une formulation linguistiquement correcte mais opérationnellement fausse. Le glossaire reste court et limité aux termes dont l’ambiguïté peut modifier le jugement.

L’attente porte également sur la traçabilité. Pour chaque information déterminante, le lecteur doit pouvoir revenir à la pièce qui la soutient ou constater que la source n’a pas été retrouvée. Le pilote n’a pas à définir ici une architecture documentaire générale. Il doit seulement vérifier qu’une sortie destinée au métier peut être contrôlée à partir du corpus autorisé.

La première réponse est comparée aux critères définis avant l’essai. Elle ne doit pas servir à réécrire ces critères après coup. Si elle révèle qu’un besoin important avait été oublié, le protocole enregistre la modification, met à jour la référence et recommence la comparaison. Il ne transforme pas l’oubli initial en réussite du système.

Le responsable métier participe aux tests, mais il ne porte pas seul la décision de lancement. Son rôle est de juger l’utilité, la justesse et la gravité des omissions. Les fonctions de sécurité jugent d’autres conditions ; le sponsor arbitre l’engagement ; les validateurs humains contrôlent les sorties. La CNIL recommande précisément d’associer les parties prenantes dès le cadrage des usages.^[16]

Écrivez la grille de lecture avant de voir la première synthèse

Une attente devient observable lorsqu’un tiers peut déterminer, sur la même sortie, si elle est satisfaite. « Synthèse claire » ne suffit pas. Il faut préciser les rubriques indispensables, les informations qui doivent être distinguées, la conduite à tenir en cas d’absence et les éléments nécessitant un retour à la pièce d’origine. La qualité rédactionnelle reste utile, mais elle ne remplace pas ces contrôles.

Le témoin humain ne doit pas être idéalisé. Les professionnels peuvent diverger sur une interprétation ou oublier un point. Le protocole consigne ces désaccords au lieu de produire artificiellement une référence unanime. Lorsqu’aucune règle métier n’existe, le pilote révèle d’abord un besoin de clarification interne. Il ne peut pas trancher seul une question que l’organisation n’a jamais décidée.

La fiche d’attente distingue le contenu obligatoire, le contenu facultatif et le contenu interdit. Une hypothèse non signalée, une recommandation présentée comme un fait ou une information tirée d’une pièce non autorisée peuvent invalider la sortie, même si les autres rubriques sont bien renseignées. La règle de validation doit refléter cette asymétrie.

Le responsable métier indique enfin le délai utile. Une sortie correcte reçue après le moment où la décision devait être prise ne répond pas au besoin. Inversement, une production rapide mais trop longue à vérifier peut déplacer la charge au lieu de la réduire. Le pilote mesure donc le traitement complet jusqu’à la validation, sans annoncer encore d’indicateur d’industrialisation.

À chaque responsabilité correspondent un objet précis, une preuve et une possibilité d’agir.

À chaque risque doit correspondre un responsable capable d’agir. Une attribution collective sans nom, délai ni suppléant laisse les défauts critiques sans propriétaire, même si le protocole paraît complet.^{[9][12][15][16][6]}

04Les dossiers difficiles révèlent les oublis de l’IA

Un pilote ne doit pas seulement vérifier que le système réussit lorsque les documents sont propres, les intitulés explicites et les informations regroupées. Il doit provoquer les situations dans lesquelles une omission, une confusion de version ou une réponse non retrouvée devient plausible. Le protocole teste donc la constance, la répétabilité, les omissions et les informations absentes sur des dossiers représentatifs.^[12][9]

La représentativité ne signifie pas reproduire statistiquement toutes les consultations reçues. À ce stade, elle consiste à inclure les variations qui changent la difficulté et la décision. Un dossier ordinaire établit le fonctionnement de base. Une pièce dégradée teste la capacité à signaler une lecture incertaine. Un renvoi entre documents éprouve la conservation du contexte. Une absence volontaire vérifie que le système sait ne pas combler le vide.

Les cas difficiles doivent être documentés avant l’essai. Si l’équipe ajoute un piège seulement après avoir observé une faiblesse, ce nouveau cas reste utile, mais il appartient à une deuxième série. Cette séparation empêche de présenter comme prévu un contrôle conçu après coup. Elle protège aussi la comparaison entre versions.

Une information non retrouvée mérite un traitement distinct d’une information fausse. Dans le premier cas, le système peut signaler sa limite et inviter à une vérification. Dans le second, il fournit un contenu susceptible d’orienter la décision dans une mauvaise direction. Les deux défauts sont enregistrés, mais leur gravité et leur conséquence ne sont pas identiques.

La répétabilité exige de rejouer la même demande dans des conditions consignées. Une réponse correcte une fois ne suffit pas si des omissions différentes apparaissent à chaque exécution. Le profil du NIST consacré aux risques de l’IA générative recommande de documenter, mesurer, surveiller et gérer les risques propres à ces systèmes.^[9] Le pilote traduit cette logique en comparaison concrète sans prétendre éliminer toute variabilité.

Le retour d’expérience du BTP fournit un repère sectoriel utile : la fiabilité ne se déduit pas de la vitesse apparente, mais d’essais reproductibles impliquant un référent métier et un contrôle humain.^[12] Cette expérience ne prouve pas qu’un résultat serait transposable à toutes les entreprises. Elle soutient la méthode d’essai, pas une promesse générale de performance.

Les difficultés à inclure dans vos tests

Le premier défaut est la qualité documentaire. Un fichier peut être mal numérisé, contenir un tableau complexe, associer plusieurs versions ou présenter une annexe difficile à lire. Le test doit vérifier si l’incertitude devient visible. Une sortie silencieusement incomplète est plus dangereuse qu’un refus explicite de répondre.

Le deuxième défaut concerne les renvois. Une exigence peut prendre son sens dans une autre pièce, une autre page ou une version ultérieure. Le système doit soit relier les éléments, soit signaler que le rapprochement n’a pas été établi. Il ne doit pas transformer une lecture partielle en certitude.

Le troisième défaut est l’exception. Une règle générale peut comporter une réserve limitée à un lot, une date ou une catégorie de prestation. Le cas test doit vérifier que cette réserve reste attachée à la règle concernée. Une synthèse qui conserve la règle mais perd son exception peut sembler correcte tout en orientant mal la décision.

Le quatrième défaut est l’absence. Une information attendue est retirée du corpus ou n’existe réellement pas. Le comportement recherché est alors une déclaration de non-disponibilité et, si le protocole le prévoit, l’indication d’une vérification humaine. Une réponse vraisemblable constitue un échec, même si elle ressemble à ce qui figure habituellement dans ce type de dossier.

05Quatre responsabilités à attribuer avant de commencer

Le sponsor, le responsable métier, les fonctions de sécurité et les validateurs humains n’examinent pas le même risque. Les réunir sous une responsabilité collective affaiblit le protocole, car personne ne sait alors qui peut accepter une réserve, qui doit la corriger et qui possède le pouvoir d’arrêter. La gouvernance commence par une attribution nominative, accompagnée d’un suppléant lorsque l’absence d’une personne pourrait laisser le pilote fonctionner sans contrôle.

Le sponsor autorise la finalité, la durée et les ressources. Il vérifie que l’essai répond à une décision réelle et que l’équipe peut consacrer du temps aux tests, aux corrections et à la reprise manuelle. Il ne valide pas seul la qualité d’une synthèse ni l’autorisation d’utiliser une donnée sensible. Son pouvoir est large sur l’engagement, mais limité sur les domaines qui exigent une compétence propre.

Le responsable métier est le garant de l’attente opérationnelle. Il décrit les informations nécessaires, juge la gravité des erreurs et participe aux essais avant toute extension. Le retour d’expérience sectoriel souligne ce rôle du référent métier dans un pilote consacré à l’analyse des appels d’offres.^[12][16] Une personne extérieure au travail quotidien peut faciliter la méthode, mais elle ne doit pas inventer les critères à la place de ceux qui prendront la décision.

Les fonctions de sécurité, de protection des données et d’informatique interviennent selon l’organisation. Elles qualifient les catégories de données, les conditions de traitement et les restrictions d’accès. Elles peuvent approuver un environnement pour un corpus précis tout en refusant une autre catégorie de documents. Leur validation ne doit jamais être résumée par le nom d’un produit supposé sûr.

Les validateurs humains contrôlent les sorties avant qu’elles influencent une décision ou deviennent un document externe. Ils doivent avoir la compétence métier, le temps et l’accès aux pièces d’origine. Une validation réduite à une lecture rapide de la forme ne satisfait pas le besoin. France Num décrit, dans un retour d’expérience du bâtiment, une première structure produite avec l’appui de l’IA puis relue systématiquement par l’humain.^[1]

Le cadre de gestion des risques du NIST insiste sur la gouvernance, la cartographie, la mesure et la gestion sur le cycle de vie.^[15] Pour l’essai, cela signifie que chaque risque a un responsable, que chaque document est vérifié par une personne désignée et que chacun sait à qui signaler un problème. Le protocole reste proportionné au cas testé, mais aucune fonction critique ne demeure implicite.

Nommer les personnes qui peuvent interrompre l’essai

Nommer un responsable sans lui reconnaître la faculté d’agir produit une gouvernance de façade. La fiche doit indiquer les situations dans lesquelles chaque personne peut suspendre le test. Le responsable métier bloque une sortie qui fausse une information décisive. La fonction de sécurité bloque une donnée ou un environnement non autorisé. Le validateur interdit un usage externe non relu. Le sponsor arrête l’expérimentation si sa finalité ou ses moyens disparaissent.

Le pouvoir de blocage s’accompagne d’une procédure de reprise. L’auteur du signalement décrit le fait observé, la pièce ou l’exécution concernée, la conséquence possible et la condition nécessaire pour recommencer. Il n’a pas à résoudre seul le problème. Cette séparation évite que la peur de ralentir l’essai conduise à minimiser un écart.

La suppléance doit être réelle. Inscrire un nom secondaire qui ne connaît ni le corpus ni les critères ne protège pas le pilote. Avant J0, chaque suppléant reçoit le protocole, les accès utiles et les conditions d’arrêt. Si aucune personne compétente ne peut reprendre le rôle pendant la période prévue, la durée ou le calendrier doit être revu.

Les désaccords sont conservés. Un sponsor peut accepter une réserve que le responsable de sécurité juge bloquante ; dans ce cas, le test ne commence pas tant que l’autorité compétente n’a pas levé le point. La hiérarchie administrative ne remplace pas l’attribution de responsabilité prévue pour le risque concerné.

06Définir une réponse acceptable avant de la lire

Les critères de qualité, de risque et d’arrêt doivent être écrits avant l’essai. Sans ce gel, l’équipe tend à valoriser ce que le système produit bien et à relativiser les défauts qu’elle n’avait pas anticipés. Le profil du NIST pour l’IA générative et son cadre général placent la mesure, la documentation et la gestion des risques au cœur de l’évaluation.^[9][15]

Le premier critère concerne la présence des informations indispensables. Une sortie peut être élégante et omettre une condition qui change la décision. La fiche métier indique donc les éléments obligatoires et la conséquence de leur absence. Cette vérification ne se réduit pas à un taux global : certaines omissions valent davantage que plusieurs informations correctement retrouvées.

Le deuxième critère porte sur la justesse. Une information présente mais attribuée à la mauvaise pièce, à la mauvaise version ou au mauvais périmètre constitue un défaut. Le contrôle revient au document source et vérifie le contexte. Une phrase exacte extraite d’une annexe peut devenir fausse si sa réserve ou son champ d’application disparaît.

Le troisième critère est la constance. Le même dossier et la même consigne sont rejoués selon la méthode prévue. Les variations sont consignées, en particulier lorsqu’elles touchent une information décisive. Le but n’est pas d’exiger une formulation identique mot pour mot, mais de vérifier que les éléments utiles et les limites restent stables.

Le quatrième critère concerne le traitement de l’absence. Le système doit reconnaître qu’une information n’est pas retrouvée au lieu de compléter par vraisemblance. La CNIL rappelle le risque d’hallucination et la nécessité d’une vérification humaine adaptée aux usages.^[6] Un constat d’incertitude correctement formulé peut être un meilleur résultat qu’une réponse fluide mais non fondée.

Le cinquième critère porte sur l’effort de validation. Le pilote observe le temps et les actions nécessaires pour vérifier la sortie, retrouver les sources et corriger les défauts. Une production plus rapide n’a pas d’intérêt si sa relecture exige de refaire entièrement le travail. Cette observation reste propre au pilote ; elle ne devient pas un calcul générique de rentabilité.

La méthode de comparaison doit rester identique entre les exécutions : même corpus gelé, même consigne, même grille et mêmes personnes ou compétences équivalentes. Tout changement est enregistré. Sinon, une amélioration attribuée au système peut provenir d’un dossier plus simple, d’une consigne enrichie ou d’un contrôle moins exigeant.

Quand tout revérifier prend trop de temps

Une erreur critique est définie par sa conséquence, pas par son apparence. Elle peut rendre une candidature irrégulière, masquer une condition déterminante, exposer une donnée non autorisée ou permettre l’utilisation externe d’un contenu non vérifié. Le protocole décrit ces catégories avant le test et indique l’issue : correction obligatoire, suspension ou arrêt.

Une accumulation de petites corrections peut également annuler l’intérêt du pilote. Si le validateur doit reprendre chaque rubrique, rechercher toutes les sources et reconstruire la logique, la sortie n’assiste plus réellement le travail. Le jugement doit porter sur le traitement complet, depuis la réception de la production jusqu’à son acceptation.

Les critères ne doivent pas devenir artificiellement numériques lorsque les sources et le contexte ne fournissent aucun seuil défendable. Il est possible de décider qu’aucune erreur critique n’est admise, que toute information déterminante doit être traçable et que la sortie doit rester vérifiable dans le délai métier. Ces règles sont plus utiles qu’un score global dont la pondération serait inventée.

La décision doit reposer sur un résultat reproductible plutôt que sur un résultat seulement séduisant. Une sortie isolée peut ouvrir une hypothèse, mais seule une comparaison préparée avant l’essai permet de soutenir le feu vert.^[9][12][15]

07Quelles erreurs doivent entraîner l’arrêt immédiat du test ?

Le protocole doit dire quand le pilote s’arrête avant même de dire comment il pourrait progresser. Cette règle empêche l’équipe de traiter chaque défaut comme une simple étape d’apprentissage. Certaines anomalies appellent une correction et un nouvel essai ; d’autres retirent immédiatement l’autorisation de continuer. Les critères d’arrêt restent liés au risque, à la qualité attendue et aux responsabilités établies.^[9][15]

Un seuil d’arrêt peut être qualitatif. Le chargement d’une donnée non autorisée, l’absence de validateur disponible, une information critique inventée ou l’impossibilité de reprendre manuellement le dossier suffisent à suspendre l’expérience. Il n’est pas nécessaire d’attendre plusieurs occurrences lorsqu’une seule expose l’entreprise à une conséquence inacceptable.

La suspension n’est pas l’abandon. Elle gèle les usages, conserve les preuves et ouvre une analyse ciblée. Le responsable concerné décrit la condition de reprise : retirer une catégorie de données, corriger le corpus, rétablir un accès, modifier la consigne ou renforcer le contrôle. Le test reprend seulement après vérification de cette condition.

L’arrêt définitif du pilote intervient lorsque la finalité disparaît, que le risque ne peut pas être ramené dans le périmètre accepté ou que le traitement manuel ne peut plus assurer la continuité. Il peut aussi être décidé si les résultats restent impossibles à interpréter malgré les corrections autorisées. La décision ne condamne pas toute expérimentation future ; elle clôt ce protocole précis.

Le pilote doit rester bloqué si le repli manuel, les responsables, les données autorisées ou les critères de réussite ne sont pas opérationnels.^{[6][9][12][15]} Cette règle ne laisse aucune de ces conditions être compensée par une démonstration réussie. Un bon résultat ne remplace pas une responsabilité absente ; une équipe motivée ne remplace pas une autorisation de données.

La procédure précise à qui signaler le problème, dans quel délai et avec quels documents. Elle évite les discussions informelles qui permettent au test de continuer pendant que la décision est repoussée. Le journal conserve l’heure de suspension, les exécutions concernées, les sorties mises en quarantaine et la personne qui autorise éventuellement la reprise.

Avant le premier essai, fixez ce qui conduira à poursuivre le pilote, à revoir son périmètre ou à l’arrêter

La première issue est la poursuite. Elle suppose que les résultats restent dans les limites acceptées, que les contrôles humains fonctionnent et qu’aucune condition bloquante n’apparaisse. La poursuite ne modifie ni le périmètre ni la durée. Elle autorise simplement les essais suivants prévus par le protocole.

La deuxième issue est la correction obligatoire. Un défaut circonscrit est documenté, les usages sont suspendus si nécessaire et une condition précise est fixée avant reprise. Le nouvel essai conserve le lien avec le résultat initial. Il ne remplace pas la preuve de l’échec par une version corrigée.

La troisième issue est l’arrêt. Elle s’applique lorsque la sécurité, la fiabilité, la continuité ou la gouvernance ne peuvent pas être rétablies dans le cadre du pilote. Le sponsor rend alors une décision motivée. Les pièces et observations restent disponibles selon les règles de conservation autorisées afin que l’entreprise comprenne ce qui a été établi.

Les revues de jalon en gestion de projet fournissent un principe utile : à des moments définis, l’avancement, les risques, les changements et les plans sont réexaminés avant de poursuivre, modifier, différer ou arrêter.^[10] Cette source établit une méthode de décision. Elle ne fournit pas un seuil propre aux appels d’offres, lequel doit venir du protocole métier et des risques réels.

08Vérifier les autorisations avant de charger un dossier confidentiel

Le caractère expérimental du pilote n’allège pas les règles applicables aux données. Il renforce au contraire le besoin de savoir quelles pièces sont utilisées, dans quel environnement et selon quelles conditions de conservation ou de réutilisation. La CNIL demande de cadrer les usages, les contrats, les données confidentielles et les modalités de déploiement ; l’ANSSI formule des recommandations de sécurité depuis la conception jusqu’à l’utilisation.^[6][7]

Un dossier peut contenir des données personnelles, des informations confidentielles, des éléments financiers, des secrets d’affaires ou des renseignements fournis par des tiers. Le responsable du corpus ne doit pas conclure seul que leur utilisation est acceptable. Les catégories sont qualifiées avec les fonctions compétentes avant tout chargement.

L’autorisation n’est pas attachée au seul nom du service. Elle porte sur une version, un mode d’accès, des paramètres, des engagements contractuels, une localisation ou des conditions d’hébergement, une politique de conservation et des règles de réutilisation. Un environnement approuvé pour des documents publics peut être refusé pour un dossier comportant des données personnelles ou confidentielles.

L’anonymisation éventuelle doit être vérifiée, pas supposée. Retirer un nom visible ne suffit pas toujours à empêcher une réidentification à partir d’autres éléments. Le protocole consigne la méthode, la personne qui l’a appliquée et la revue réalisée. Si l’anonymisation détruit une information nécessaire au test, cette limite est enregistrée dans la portée du résultat.

Les accès sont bornés à l’équipe du pilote. La gestion des identités et des autorisations aide à savoir qui peut consulter les documents, charger une nouvelle pièce ou récupérer une sortie.^[8] Le pilote ne définit pas ici une politique générale d’accès pour l’entreprise. Il vérifie que les comptes nécessaires existent, que les droits correspondent aux rôles et qu’ils peuvent être retirés à la clôture.

Les conditions de conservation doivent être compatibles avec la durée de l’essai et la preuve attendue. Conserver indéfiniment les dossiers parce que le test pourrait être rejoué plus tard n’est pas une décision acceptable par défaut. Le protocole indique ce qui est gardé, pourquoi, jusqu’à quelle échéance et qui ordonne la suppression ou l’archivage autorisé.

La réutilisation pour améliorer un service, entraîner un modèle ou fournir une autre fonctionnalité doit être connue et contrôlée. Une clause imprécise ou une absence d’information empêche le feu vert pour les données concernées. L’équipe peut décider de préparer un corpus moins sensible, mais elle doit alors limiter explicitement la portée du résultat.

Vérifier quelles données l’outil est autorisé à traiter

Deux validations séparées ne suffisent pas : une donnée jugée utilisable en interne et un environnement approuvé pour un autre usage ne forment pas automatiquement une combinaison autorisée. La fiche relie chaque catégorie de données à l’environnement précis qui la recevra, aux personnes autorisées et à la durée prévue.

Toute modification des données ou de leurs conditions de traitement impose une nouvelle vérification. Ajouter un type de pièce, activer une fonction de partage, modifier l’hébergement ou ouvrir un accès extérieur change l’autorisation. La décision ne peut pas être déduite de la proximité avec le scénario initial.

Le responsable sécurité dispose d’un veto propre. Le sponsor peut demander une solution de remplacement ou un corpus différent, mais il ne transforme pas une réserve non levée en acceptation. Cette règle protège aussi les participants : ils n’ont pas à interpréter seuls des conditions contractuelles ou techniques qu’ils ne maîtrisent pas.

Cette matrice relie la nature des informations à la preuve exigée avant le chargement.

L’autorisation suit la donnée jusque dans son environnement. Elle devient caduque dès que la catégorie, le mode de traitement, les accès ou les conditions de conservation changent.^[6][7]

09Pouvoir reprendre le dossier sans l’IA

Le repli manuel n’est pas une intention de revenir aux anciennes habitudes si le pilote déçoit. C’est une procédure testée qui permet de reprendre le dossier sans dépendre d’une sortie indisponible, douteuse ou bloquée. Il doit fonctionner avant la première production, car une difficulté peut survenir dès le chargement, pendant l’analyse ou au moment de la validation.

La procédure indique qui reprend le travail, avec quels accès, à partir de quel état du dossier et dans quel délai utile. Elle identifie les informations déjà vérifiées qui peuvent être conservées et celles qui doivent être reprises depuis les pièces d’origine. Sans cette précision, l’équipe risque de perdre du temps à déterminer ce qui reste fiable au moment même où l’échéance approche.

Une sortie générée ne doit pas devenir une décision ou un document externe sans vérification humaine appropriée.^[6][1][12] Cette règle exige un validateur compétent, disponible et doté des sources nécessaires. Une mention générale selon laquelle l’humain reste responsable ne suffit pas si personne n’est désigné ou si le calendrier ne laisse aucun temps de contrôle.

Le test du repli part d’un incident simulé. L’accès au système peut être indisponible, une information critique peut être fausse ou le responsable sécurité peut suspendre l’usage. L’équipe arrête alors le traitement assisté, récupère le corpus autorisé et poursuit manuellement. Le chronométrage commence au signal de bascule et s’achève lorsque le travail retrouve un état exploitable.

Le résultat ne se résume pas à une durée. Le procès-verbal note les accès manquants, les compétences sollicitées, les doublons, les informations perdues et les décisions qui ont dû être reprises. Il distingue le temps incompressible du traitement manuel du surcroît créé par une mauvaise préparation du repli.

La reprise doit fonctionner avec un suppléant lorsque le titulaire du rôle constitue un point de fragilité évident. Le but n’est pas de doubler toute l’équipe, mais d’éviter qu’une personne absente rende le processus impossible. Si aucune suppléance réaliste n’existe, le calendrier du pilote doit être adapté ou le lancement différé.

Le dépôt électronique et les échanges avec l’acheteur obéissent à des modalités précises de profil, de formats et de sauvegarde.^[14] Le repli testé ici reste en amont de ces opérations : il garantit que l’équipe peut reprendre son travail de qualification ou de préparation, sans prétendre couvrir la remise de l’offre elle-même.

Mesurer le temps nécessaire pour reprendre le travail

Le scénario commence avec un dossier dont l’équipe connaît les contraintes. Un événement de bascule est annoncé sans préparation de dernière minute. Les participants appliquent la procédure disponible, retrouvent les pièces et reprennent la tâche. Toute aide improvisée est notée, car elle révèle une dépendance absente du protocole.

Le chronométrage doit couvrir la remise en état, pas seulement l’ouverture des fichiers. Si le validateur doit identifier la bonne version, reconstruire les points déjà traités ou vérifier quelles données ont circulé, ces opérations appartiennent au repli. Le délai utile est comparé à l’échéance métier définie avant le test.

La procédure précise le statut des sorties produites avant l’incident. Elles peuvent être écartées, conservées comme notes à vérifier ou reprises après une nouvelle autorisation. Aucun participant ne doit décider seul de les réutiliser parce qu’elles paraissent plausibles. Mettre ces résultats à l’écart évite de les réutiliser sans vérification pendant la reprise du travail.

Le retour d’expérience de France Num sur une entreprise du bâtiment met en avant la relecture humaine systématique d’une première structure de réponse.^[1] Celui consacré au pilote d’analyse souligne les tests reproductibles, la fiche de synthèse et l’implication métier.^[12] Ces exemples soutiennent la nécessité d’une reprise contrôlée, sans prouver qu’un délai particulier conviendrait à toutes les organisations.

1. 01

   Déclencher la bascule

   Le responsable signale l’incident, suspend l’usage et identifie les sorties concernées.

2. 02

   Récupérer le dossier

   L’équipe retrouve les pièces, les versions et les accès nécessaires sans dépendre du système testé.

3. 03

   Reprendre la tâche

   Le professionnel poursuit le traitement selon la méthode manuelle de référence.

4. 04

   Contrôler les traces

   Les contenus antérieurs sont écartés ou vérifiés selon leur statut et leur risque.

5. 05

   Consigner la preuve

   Un exercice réel montre si la reprise manuelle fonctionne.^{[1][6][12][15][9]}

Une sortie générée reste une proposition tant qu’elle n’est pas vérifiée. Sa fluidité, sa rapidité ou sa ressemblance avec un document terminé ne lui confèrent aucun pouvoir de décision.^[1][6][12]

Chaque erreur critique est reliée à un contrôle, à une décision immédiate et à une reprise déterminée.

Une erreur critique suspend l’essai et déclenche le repli prévu. La matrice interdit qu’un défaut grave soit absorbé dans une moyenne de qualité ou compensé par plusieurs résultats corrects.^{[1][6][9][12][15]}

10La décision de lancer l’essai doit pouvoir se justifier

La décision finale doit être lisible sans reprendre tout le journal du pilote. Une fiche rassemble le périmètre, le corpus, les responsables, les critères, les données autorisées, le repli et les réserves. Chaque case renvoie à une preuve disponible. Le lecteur peut accepter le résultat, demander une précision ou contester une condition sans devoir reconstruire le raisonnement à partir de comptes rendus dispersés.

Le feu vert ne signifie pas que l’IA est approuvée pour les appels d’offres en général. Il autorise une expérience définie sur un type de dossier, avec une équipe, une durée et une sortie prévues. Toute extension reste interdite jusqu’à une nouvelle décision. Cette limitation doit apparaître dans la première partie de la fiche, pas dans une note secondaire.

Le report est une décision complète. Il nomme les conditions non réunies, leurs responsables et la preuve attendue pour rouvrir l’examen. Une date peut être fixée si elle correspond à une action réelle. Le report ne laisse pas le test se poursuivre officieusement pendant que les réserves restent ouvertes.

Le refus est également motivé. Il peut résulter d’un risque non maîtrisé, d’un besoin mal défini, d’une incapacité à constituer un corpus représentatif ou d’un repli impraticable. La fiche précise si le refus porte sur le pilote actuel ou sur toute expérimentation dans la situation considérée. Cette nuance évite de transformer une décision prudente en condamnation générale.

La décision bid ou no-bid possède ses propres méthodes et critères, notamment lorsqu’elle combine appréciations expertes, pondérations et incertitude.^[11] Le feu vert du pilote ne remplace pas cette décision commerciale. Il détermine seulement si l’entreprise peut expérimenter l’IA pour soutenir une partie du travail qui précède ou prépare ses arbitrages.

La recherche et l’analyse documentaires assistées par l’IA peuvent couvrir synthèse, classification et extraction d’informations.^[13] Cette diversité fonctionnelle ne doit pas élargir la fiche. Celle-ci décrit uniquement la fonction réellement testée. La présence d’autres possibilités dans le même environnement ne constitue ni une autorisation ni une preuve de valeur.

Le décideur signe après les responsables compétents. Il ne se contente pas de constater leur présence ; il vérifie que les réserves bloquantes sont levées et que les conditions du oui sont vérifiables. Si deux avis se contredisent, la fiche conserve le désaccord et la décision reste différée jusqu’à ce que l’autorité appropriée tranche.

Écrire ce qui est autorisé et ce qui reste à vérifier

Le cadrage doit réunir les éléments nécessaires à une décision explicite ; leur sélection, leur articulation et leur formalisation dépendent du contexte. Aucune case ne peut être remplacée par une mention vague telle que « validé par l’équipe ».

Chaque preuve possède une date, un propriétaire et un statut. Une preuve en préparation n’est pas une preuve acquise. Une autorisation orale non consignée ne permet pas de charger des données. Un repli décrit mais non exécuté reste une intention. Cette discipline évite que la proximité de J0 transforme les actions prévues en conditions supposées remplies.

La fiche sépare les conditions bloquantes des améliorations souhaitables. Les premières doivent être satisfaites avant le lancement. Les secondes peuvent être planifiées pendant le pilote si elles ne modifient ni le risque accepté ni l’interprétation des résultats. Cette distinction protège le protocole contre deux excès : lancer avec une faiblesse critique ou retarder indéfiniment pour atteindre une perfection sans rapport avec le test.

Le feu vert final tient en une phrase : le pilote est autorisé dans le périmètre décrit jusqu’à l’échéance indiquée, sous réserve des contrôles et seuils annexés. Le report et le refus disposent d’une formulation aussi explicite. Il n’existe pas d’état intermédiaire où l’équipe commencerait « pour voir » avant la décision.

Une entreprise prête à lancer n’a pas supprimé toute incertitude. Elle sait laquelle elle accepte, qui la surveille et dans quelles conditions le travail reprend. Le feu vert transforme cette maîtrise en décision datée, motivée et réversible.