De l’idée au pilote : réussir un projet IA mesurable

Beaucoup d’organisations ont déjà « testé l’IA ». Un assistant branché sur quelques documents, une démonstration convaincante en réunion, puis plus rien. Le pilote n’a pas échoué, à proprement parler. Il n’a simplement jamais permis de prendre une décision.

C’est le symptôme le plus fréquent que je rencontre : un projet d’IA lancé à partir d’une technologie plutôt qu’à partir d’une question. On se demande ce qu’un modèle de langage pourrait faire, au lieu de se demander quel problème mérite d’être résolu, et comment on saura qu’il l’est.

Voici la démarche que j’applique, nourrie par des projets concrets : un banc d’essai de lecture de cartes de complémentaire santé, un coach conversationnel intégré à une application d’entraînement, et des agents qui préparent une partie de mes propres opérations.

Commencer par la décision, pas par le modèle

Un pilote utile se termine par une décision : étendre, ajuster ou arrêter. Si personne ne sait, au lancement, sur quels critères cette décision sera prise, le pilote produira une impression, pas une réponse.

Avant de choisir un modèle, j’écris donc trois choses avec le client. La tâche précise que le système doit accomplir, formulée en termes métier : lire tel champ sur tel document, répondre à telle catégorie de question. Le critère de réussite, mesurable sur des cas réels : une proportion de champs corrects, un temps de traitement, une part de réponses acceptables. Et la condition d’arrêt : ce qui, si on l’observe, signifie que l’approche ne convient pas.

Cette dernière est la plus difficile à écrire, et la plus utile. Un pilote qui ne peut pas échouer ne peut rien démontrer.

Construire de quoi comparer avant de choisir

Le deuxième piège consiste à choisir un outil avant d’avoir de quoi le juger. Sur un sujet comme la lecture de documents, il existe des dizaines de solutions : services d’OCR hébergés, modèles de vision généralistes, modèles open-weight que l’on peut faire tourner chez soi. Chacune a ses forces, ses coûts et ses contraintes de confidentialité.

Pour Santécie, plutôt que de brancher le service le plus connu et de le juger sur quelques exemples, j’ai d’abord construit un banc d’essai. Chaque pipeline y est versionné et produit des artefacts qui ne changent plus. On peut ainsi comparer deux moteurs, ou deux réglages du même moteur, sur les mêmes images, sans se demander si quelque chose a bougé entre les deux essais.

Ce travail paraît lent au départ. En réalité, il accélère tout le reste : chaque nouvelle option se teste en quelques heures, et la discussion porte sur des résultats, pas sur des promesses commerciales.

Traiter la confidentialité comme une contrainte de conception

Sur des données sensibles, la question « où les données sont-elles traitées ? » n’est pas un détail à régler après le pilote. Elle détermine les options possibles.

Dans le cas des cartes de complémentaire santé, le traitement est conçu pour rester sur le poste de l’utilisateur. Le recours à une API externe n’est envisagé que pour le banc d’essai, et seulement avec une garantie de rétention nulle. Une partie du travail a consisté à analyser les offres d’OCR hébergées sous contrainte HDS, leurs engagements de confidentialité, et les conditions dans lesquelles un modèle open-weight pourrait être servi sur une infrastructure maîtrisée.

Ce cadrage écarte d’emblée certaines solutions. C’est précisément son intérêt : le pilote ne débouchera pas sur une option que la conformité refusera ensuite.

Borner ce que le modèle peut faire

Un modèle de langage branché sans limites produit vite des réponses plausibles mais fausses. Sur un sujet qui touche à la santé ou à l’argent, ce n’est pas acceptable.

Dans l’application d’entraînement développée pour Essan NFC, le coach conversationnel ne répond pas « de mémoire ». Il récupère le contexte de l’utilisateur au moyen de commandes en lecture seule, procède par cycles de recherche bornés, et ne peut rien modifier. Il s’appuie sur ce qui est connu de l’utilisateur et de la méthode, pas sur des généralités. Les conseils restent par ailleurs informatifs : ils ne remplacent pas un avis médical, et l’application le dit.

Le projet a aussi exploré l’exécution d’un modèle compact directement sur le téléphone, pour la confidentialité et le fonctionnement hors ligne. Cette piste est restée une expérimentation de développement : elle a permis de mesurer les contraintes réelles (taille, rapidité, qualité) sans les imposer au produit. C’est exactement le rôle d’une exploration : apprendre quelque chose qui peut changer une décision, sans se transformer en engagement implicite.

Mettre la validation humaine dans le processus

Un pilote d’IA qui fonctionne pose immédiatement une autre question : qui est responsable de ce que le système produit ?

Ma réponse est constante : le système prépare, une personne valide. Sur le démonstrateur de lecture de cartes, chaque champ proposé est vérifié par un humain avant confirmation. Dans mes propres opérations, des agents préparent les brouillons de facture et d’email, mais rien ne part sans mon accord. Cette validation n’est pas un bouton ajouté à la fin : c’est une étape du processus, conçue dès le départ, et vérifiée sur des données précises.

Ce choix a une conséquence heureuse sur la mesure. Chaque correction humaine est une donnée : elle dit où le système se trompe, et à quelle fréquence. Le pilote produit ainsi, en fonctionnant, les indicateurs qui permettront de décider de son extension.

Écrire les limites aussi clairement que les résultats

Le dernier point est une question d’honnêteté, et de crédibilité. Un pilote produit des résultats partiels. Les présenter comme définitifs, c’est préparer la déception.

Je rédige donc chaque synthèse de pilote avec une section consacrée aux limites : ce qui n’a pas été testé, les cas où le système échoue, les hypothèses qui restent à vérifier. Sur le banc d’essai OCR, par exemple, la documentation affirme explicitement qu’il s’agit d’un démonstrateur, sans revendication de qualité de production ni de conformité médicale. Cette transparence n’affaiblit pas le projet. Elle permet au client de décider en connaissance de cause.

La démarche en résumé

1. Formuler la décision que le pilote doit permettre, avec un critère de réussite et une condition d’arrêt.
2. Construire de quoi comparer avant de choisir un modèle ou un fournisseur.
3. Fixer le cadre de confidentialité dès le départ, pour ne pas explorer des options inutilisables.
4. Borner le modèle : contexte maîtrisé, accès en lecture seule, périmètre explicite.
5. Intégrer la validation humaine comme étape du processus, et en faire une source de mesure.
6. Documenter les limites avec autant de soin que les résultats.

Un projet d’IA mesurable n’est pas plus lent qu’un autre. Il évite simplement de recommencer, six mois plus tard, le même pilote sans conclusion.