Cadrer un projet IA : ce qu’il doit prouver avant la première ligne de code
Cadrer un projet IA, c’est écrire en une à deux semaines, avec le client, un document de quelques pages qui dit ce que le système doit prouver, sur quel processus, contre quelle base de référence, et à quel moment on s’arrête. Chez nos clients, ce document précède toute ligne de code, et c’est lui qui fait sortir un projet du POC au lieu d’y rester.
Il tient en huit rubriques, dont aucune n’est technique : le cadrage engage la direction et le métier avant les développeurs.
Les huit rubriques du document de cadrage
- Le processus visé et son volume
- La décision ou l’action que l’IA prend ou prépare
- La base de référence mesurée avant le projet
- Le critère de succès chiffré, fixé par le métier
- Les données disponibles et leurs limites
- Les contraintes : RGPD, hébergement, systèmes à intégrer
- Le périmètre de la première version et ce qui en est exclu
- Le responsable métier nommé
La deuxième rubrique est celle qui tranche. "L’IA prépare une proposition qu’un commercial valide" et "l’IA répond au client" sont deux projets différents, avec des contrôles, des risques et des coûts sans rapport, et beaucoup de projets flottent parce que personne n’a choisi.
La base de référence et le critère de succès vont ensemble : mesurer le processus avant d’y toucher, puis dire quel écart suffira pour passer en production. Le critère est écrit par le métier, en unités du métier, et jamais par le prestataire, qui écrirait celui qu’il est sûr d’atteindre.
Les contraintes sont des décisions d’architecture : l’hébergement, la minimisation des données et les contrats avec les fournisseurs de modèles se choisissent avant de construire, et un projet qui les découvre en semaine douze repart de zéro. Le périmètre, enfin, se définit autant par ce qu’il exclut que par ce qu’il contient.
Un exemple anonymisé : les demandes de devis d’un distributeur
Un distributeur de matériel professionnel reçoit plusieurs centaines de demandes de devis par semaine, par email. Une équipe d’administration des ventes cherche les références au catalogue, vérifie les conditions du client dans l’ERP et renvoie un devis. Le cadrage écrit avec le directeur commercial tenait sur cinq pages.
Le processus : les demandes de devis entrantes d’une seule agence, par email, hors appels d’offres. La décision : l’IA prépare un brouillon de devis avec les références et les prix du client, un gestionnaire valide avant envoi, l’IA n’envoie rien. La base de référence : le temps moyen par devis et le taux de devis renvoyés pour correction, mesurés pendant trois semaines avant le projet. Le critère de succès : réduire le temps par devis d’une proportion fixée par le directeur commercial, sans augmenter le taux de correction. Les données : deux ans de demandes avec leurs devis, et un catalogue dont une partie des fiches est périmée, écrit noir sur blanc. Les contraintes : données clients dans l’ERP, hébergement en Europe, pas d’envoi automatique. Exclus de la première version : les appels d’offres, les autres agences, les demandes téléphoniques. Responsable métier : la responsable de l’administration des ventes de l’agence, deux heures par semaine.
Rien dans ce document ne nomme un modèle ni une architecture ; ces choix viennent après, à partir de ce que le document fixe.
Pourquoi le cadrage évite le POC sans fin
Le POC sans fin a une cause unique : personne n’a écrit ce qu’il devait prouver, donc personne ne peut dire s’il a réussi. Chaque démonstration appelle une nouvelle demande, chaque nouvelle demande prolonge d’un mois, et le projet meurt d’épuisement plutôt que par décision. La plupart des échecs de projets IA que nous voyons tiennent à cela plus qu’à une difficulté technique.
Avec un critère de succès écrit, le prototype a une fin : à la date fixée, soit il bat le critère et passe en intégration, soit le projet s’arrête ou se réoriente, et les deux issues sont des réussites de cadrage. Le périmètre écrit joue le même rôle contre l’extension permanente : quand quelqu’un demande d’ajouter les appels d’offres en semaine quatre, la réponse est dans le document, signée par le directeur commercial.
Le cadrage comme contrat avec le prestataire
Le document sert ensuite de pièce d’appel d’offres. Un prestataire qui reçoit une baseline, un critère chiffré et un périmètre exclu peut proposer un prix et un calendrier engageants ; un prestataire qui reçoit "nous voulons faire de l’IA sur nos devis" proposera des ateliers. Les questions qui font le tri entre prestataires se posent bien mieux avec le document en main, parce que les réponses se comparent à quelque chose.
Il protège aussi le client pendant le projet : le critère de succès devient la condition d’acceptation, le périmètre devient le devis, et les deux sont écrits avant la signature, ce qui change les conversations à mi-parcours. Il arrive que le cadrage conclue qu’un outil du marché couvre le besoin, auquel cas la grille développer ou acheter s’applique sans qu’un développement ait été engagé.
Une à deux semaines, quelques pages, un responsable métier et des chiffres de départ : c’est un investissement modeste pour un projet qui se comptera en mois. Nous commençons chaque mission d’IA sur mesure par ce document, et nous le rédigeons avec vous, que la construction nous revienne ensuite ou qu’elle aille à quelqu’un d’autre.