Quand un projet d'IA s'arrête, l'explication donnée est rarement la bonne. On parle de performance du modèle, de qualité des réponses, de maturité de la technologie.
Notre expérience de déploiement dit autre chose. Les projets qui échouent s'arrêtent parce que personne n'a été nommé pour arbitrer, parce que le périmètre s'est étendu sans décision, parce qu'aucun critère de succès n'avait été écrit au départ, ou parce que les utilisateurs n'avaient pas de temps alloué pour s'approprier l'outil.
Aucune de ces causes n'est technique. Toutes sont vérifiables avant de commencer.
Nous vérifions désormais sept prérequis avant de nous engager, et nous refusons les projets où plusieurs manquent. Ce n'est pas de la sélection de clients : un projet lancé sans ces conditions échoue, et cet échec coûte plus cher à tout le monde qu'un refus initial.
Un propriétaire métier nommé
Le premier prérequis, et celui dont l'absence est la plus fatale.
Il faut une personne, identifiée par son nom, qui décide. Quels documents font autorité. Quelle réponse est juste quand deux sources se contredisent. Quel usage est prioritaire. Quand le résultat est suffisant pour être mis entre les mains des utilisateurs.
Cette personne n'est pas un chef de projet informatique. C'est un praticien du métier concerné, qui connaît l'histoire des documents et les habitudes réelles de ses collègues.
Sans elle, le projet avance jusqu'au premier arbitrage, puis s'enlise. Les questions remontent, personne ne tranche, et le calendrier glisse pour des raisons que personne ne sait expliquer.
Le signal d'alerte est facile à repérer : quand on demande qui décide et que la réponse est « on en discutera en comité », le prérequis n'est pas rempli.
Un périmètre délimité et signé
Un périmètre écrit, avec ce qui en fait partie et surtout ce qui n'en fait pas partie.
L'extension progressive est le mode d'échec le plus courant et le plus insidieux, parce que chaque ajout paraît raisonnable pris isolément. On commence par un corpus documentaire, on ajoute une intégration, puis un second métier, puis un cas particulier. À la fin, plus rien n'est terminé.
La règle qui fonctionne : tout ajout au périmètre initial fait l'objet d'une décision explicite, avec son impact sur le calendrier. Ce n'est pas une rigidité contractuelle, c'est ce qui permet de livrer quelque chose.
Des données existantes et exploitables
Il faut que les documents existent, qu'ils soient accessibles, et qu'ils soient lisibles.
Ces trois conditions ne vont pas de soi. Un corpus peut exister sans être accessible, parce qu'il est dispersé dans des boîtes courriel personnelles. Il peut être accessible sans être exploitable, parce qu'il s'agit de scans sans couche de texte, ou de tableaux dont la structure se perd à l'extraction.
Le test qui tranche : prendre trente documents représentatifs et vérifier ce qu'on en extrait réellement. Cette vérification prend une demi-journée et évite des mois d'illusion.
Un corpus dégradé ne produit pas un système dégradé. Il produit un système qui répond avec assurance à partir d'informations fausses, ce qui est nettement pire.
Un critère de succès mesurable, écrit avant
Il faut savoir, avant de commencer, à quoi on reconnaîtra que le projet a réussi.
« Gagner du temps » n'est pas un critère. « Réduire de moitié le temps de recherche d'une clause type dans nos contrats, mesuré sur dix cas réels » en est un.
L'absence de critère produit une situation caractéristique : le projet fonctionne, et personne ne sait dire s'il a réussi. Chacun juge selon ses attentes implicites, qui divergent. Le projet s'éteint sans décision, faute d'avoir jamais défini ce qu'on en attendait.
Écrire ce critère avant le démarrage a un autre mérite : la discussion révèle souvent que les parties prenantes n'attendaient pas la même chose.
Une décision d'accès prise avant l'indexation
Qui a le droit de voir quoi. Cette question doit être tranchée avant que les documents entrent dans le système, pas après.
La raison est mécanique : une fois un corpus indexé, toute personne ayant accès à ce corpus peut en obtenir des extraits par une question. Si des documents sensibles ont été indexés dans un espace largement ouvert, le problème ne se corrige pas par un réglage d'affichage. Il faut réindexer.
Sur ce point, notre architecture aide : chaque projet dispose de sa propre base documentaire, physiquement distincte, plutôt qu'un filtre appliqué à une base commune. Il n'y a pas de condition à oublier, parce qu'il n'y a rien à filtrer. Mais cette séparation ne décide pas à la place du client de ce qui va dans quel espace.
Du temps utilisateur réellement alloué
Un système documentaire ne s'impose pas par sa qualité. Il s'adopte parce que des personnes ont eu le temps de l'essayer, de constater ses limites, et d'ajuster leur manière de l'interroger.
Ce temps doit être alloué explicitement. « Les utilisateurs testeront quand ils auront un moment » signifie qu'ils ne testeront pas : ils ont déjà un travail.
L'ordre de grandeur que nous demandons est modeste, quelques heures par référent métier réparties sur les semaines de mise en œuvre. Mais ces heures doivent être inscrites quelque part, sinon elles n'existent pas.
C'est le prérequis le plus facile à accorder verbalement et le plus souvent non tenu.
Une politique d'usage validée
Que fait-on quand le système se trompe. Qui relit avant qu'une réponse serve à décider. Quels usages sont interdits.
Ces questions paraissent théoriques avant la mise en service, et deviennent urgentes le jour où quelqu'un utilise une réponse dans un document remis à un client.
Une politique d'usage tient en une page. Elle indique les usages autorisés, ceux qui exigent une relecture humaine, et ceux qui sont exclus. Sur des domaines à conséquences juridiques ou médicales, aucun taux de fiabilité ne justifie de retirer la relecture.
La bonne question n'est pas « le système est-il fiable ? » mais « que se passe-t-il quand il se trompe ? ». Une organisation qui n'a pas de réponse à cette seconde question n'est pas prête, quelle que soit la qualité de l'outil.
Ce qui se passe quand plusieurs manquent
Nous refusons les projets où plusieurs prérequis manquent, et je veux être précis sur le raisonnement.
Ce n'est pas une posture. C'est le constat qu'un projet lancé dans ces conditions produit trois perdants : le client qui a dépensé sans résultat, ses utilisateurs qui ont perdu confiance dans une technologie qu'ils associeront désormais à un échec, et nous, dont la référence est mauvaise.
Un refus initial coûte une opportunité commerciale. Un échec coûte tout cela.
En revanche, un prérequis manquant n'est pas rédhibitoire s'il est reconnu et traité. L'absence de propriétaire métier se corrige en en nommant un. Un corpus non exploitable se corrige par un travail préalable de sélection. Ce qui est fatal, c'est de démarrer en faisant comme si la condition était remplie.
Comment vérifier, concrètement
Ces sept points se vérifient en une réunion, à condition de poser les bonnes questions.
- Qui décide, nommément, quand deux documents se contredisent ?
- Qu'est-ce qui ne fait pas partie du projet ?
- Pouvons-nous prendre trente documents réels et regarder ce qu'on en extrait ?
- À quoi saurez-vous, dans trois mois, que cela a marché ?
- Quels documents ne doivent pas être visibles par tous, et par qui ?
- Combien d'heures les référents métier peuvent-ils y consacrer, et est-ce écrit ?
- Que fait-on quand le système donne une réponse fausse ?
Une organisation qui répond à ces sept questions est prête. Une organisation qui bute sur trois d'entre elles a un travail préalable à faire, et ce travail lui sera utile indépendamment du projet.
Ce qu'il faut retenir
La technologie de recherche documentaire et d'assistance est mûre. Ce n'est plus là que se joue le résultat.
Ce qui décide, ce sont des conditions organisationnelles : quelqu'un qui tranche, un périmètre tenu, des données lisibles, un critère écrit, des accès décidés avant l'indexation, du temps utilisateur réel, et une politique claire face à l'erreur.
Ces conditions se vérifient en amont, en quelques heures. C'est le meilleur investissement d'un projet d'IA, et le plus souvent négligé, parce qu'il ne ressemble pas à du travail technique.
