Rubriques

Intelligence artificielle Automatisation Veille Écosystème lyonnais

Le site

Tous les articles Le média Nous écrire
Intelligence artificielle

Cadrer un projet IA : la méthode en quatre étapes avant d’écrire du code

Problème, mesure de succès, données, scénario de repli : quatre étapes, quatre livrables d’une page. Et le droit de s’arrêter là si le calcul ne tient pas.

Cadrer un projet IA : la méthode en quatre étapes avant d’écrire du code

La plupart des projets d’intelligence artificielle qui échouent n’échouent pas sur la technique. Ils échouent parce que personne n’a écrit noir sur blanc quel problème ils résolvaient, ni comment on saurait qu’ils l’avaient résolu. Cadrer un projet IA, c’est produire ces réponses avant de choisir un modèle, un prestataire ou une plateforme.

Le symptôme est reconnaissable : une démonstration convaincante en trois semaines, puis six mois d’enlisement sur des cas particuliers, et une mise en production repoussée jusqu’à l’oubli. Entre les deux, il manquait un cadrage, c’est-à-dire un travail écrit de quelques jours qui coûte mille fois moins cher qu’un projet abandonné en cours de route.

Réussir un projet IA tient moins au choix de la technologie qu’à ce travail écrit de quelques jours. Cette méthode tient en quatre étapes. Chacune se termine par un livrable d’une page, relu et validé par une personne qui n’a pas participé à sa rédaction. Si les quatre pages ne tiennent pas debout, le projet ne démarre pas : c’est le principal service que rend un cadrage.

Étape 1 : écrire le problème sans nommer la solution

La première page décrit une situation actuelle, pas une technologie. La contrainte de rédaction est simple : le mot « IA » n’a pas le droit d’y figurer. Si vous n’arrivez pas à décrire le problème sans nommer l’outil, c’est que vous partez de l’outil.

Un problème bien écrit contient toujours quatre éléments : qui subit la situation, à quelle fréquence, ce que ça coûte, et ce qui se passe aujourd’hui faute de mieux. Comparez ces deux formulations.

Formulation faible« Mettre en place un agent IA pour le service client. »
Formulation exploitable« Trois personnes du service client traitent environ 400 courriels par semaine, dont 60 % sont des demandes de suivi de commande auxquelles la réponse existe déjà dans notre outil de gestion. Le délai moyen de réponse est de 11 heures, contre 4 heures annoncées aux clients. »

La seconde formulation ne dit rien de la solution, et pourtant elle contient déjà tout : le volume, la part adressable, l’écart à combler. Elle permet aussi de découvrir que la meilleure réponse n’est peut-être pas un projet IA mais une intégration entre deux logiciels. Notre article sur les processus à automatiser en premier dans une PME détaille cette grille de tri.

Livrable : une page décrivant la situation actuelle, avec au moins trois chiffres mesurés (pas estimés) et la description de ce qui est fait aujourd’hui.

Étape 2 : définir la mesure du succès avant de commencer

Un cahier des charges IA sans critère de succès chiffré produit un débat d’opinions à la livraison. La deuxième page fixe ce critère, et surtout le seuil en dessous duquel on considère que ça n’a pas marché.

Un bon critère respecte trois conditions : il est mesurable avec les outils que vous avez déjà, il est mesuré aujourd’hui (sinon vous n’aurez pas de point de comparaison), et il porte sur le résultat métier, pas sur la technologie. « Le modèle a un taux de bonne réponse de 92 % » est un indicateur technique. « Le délai moyen de première réponse passe de 11 heures à moins de 4 heures, sans dégrader la satisfaction mesurée » est un critère de succès.

Fixez aussi le contraire, ce qu’on appelle parfois le critère d’échec : « si, au bout de huit semaines, moins de 30 % des demandes sont traitées sans intervention humaine, on arrête ». Écrit à froid, ce seuil est facile à poser. Écrit six mois plus tard, quand le budget est engagé, il ne s’écrit plus. La méthode de relevé est détaillée dans notre article sur la façon de mesurer le gain réel d’un usage IA.

Livrable : une page avec deux ou trois indicateurs, leur valeur actuelle mesurée, la valeur cible, la date d’évaluation et le seuil d’arrêt.

Étape 3 : regarder les données avant de promettre quoi que ce soit

C’est l’étape la plus souvent sautée, et celle qui tue le plus de projets en phase de réalisation. Un système d’IA appliqué à vos processus s’appuie sur votre matière : documents, historiques, fiches, échanges. Cette matière est rarement dans l’état qu’on imagine.

Quatre questions à traiter, dans l’ordre :

  • Existe-t-elle ? Les réponses aux demandes récurrentes sont-elles écrites quelque part, ou dans la tête de deux personnes ? Si la connaissance n’est pas écrite, le premier chantier est de l’écrire.
  • Est-elle accessible ? Un accès technique existe-t-il (export, interface de programmation), ou faut-il passer par un écran ? Une donnée qui ne sort de son logiciel que par copier-coller coûte cher.
  • Est-elle propre ? Doublons, versions concurrentes d’un même document, procédures périmées. Un assistant nourri de deux procédures contradictoires répondra les deux.
  • A-t-on le droit de l’utiliser ? Données personnelles, base légale, information des personnes, durée de conservation, sous-traitance. Le cadre est posé dans notre article sur le RGPD et l’IA en entreprise, et cette question se traite au cadrage, pas à la recette.

Livrable : une page listant les sources de données, leur volume, leur mode d’accès, leur état de propreté et le régime juridique applicable.

Étape 4 : écrire le scénario de repli

La quatrième page décrit ce qui se passe quand le système se trompe, tombe en panne, ou n’est pas sûr de lui. Un projet d’intelligence artificielle sans scénario de repli n’est pas prêt pour la production, quelle que soit la qualité de sa démonstration.

Trois situations à traiter explicitement :

  1. Le doute : quand le système n’a pas de réponse fiable, que fait-il ? Il transmet à un humain, avec quel délai, vers quelle file ?
  2. L’erreur : comment la détecte-t-on, qui la corrige, et comment évite-t-on qu’elle se reproduise à l’identique ?
  3. L’indisponibilité : si le fournisseur est en panne une demi-journée, le travail s’arrête-t-il ? Le mode dégradé doit être écrit et testé.

Cette page force aussi une décision de gouvernance : qui est responsable de ce que le système produit. La réponse ne peut pas être « le prestataire ». Elle détermine les critères de choix développés dans notre article sur la façon de choisir un prestataire IA.

Livrable : une page décrivant le comportement en cas de doute, la procédure de correction, le mode dégradé et le nom du responsable.

Cadrer un projet IA : le calcul final, et le droit de s’arrêter là

Les quatre pages en main, le calcul se fait en une demi-journée. D’un côté le gain annuel estimé à partir de l’étape 2, de l’autre le coût complet : mise en place, abonnements, consommation à l’usage, temps interne de supervision, maintenance. Notre article sur le coût d’un projet d’IA générative en entreprise donne les postes que l’on oublie systématiquement, et celui sur la mesure du retour sur investissement d’une automatisation propose une trame de calcul réutilisable.

Si le rapport est défavorable, ou si l’étape 3 révèle que la matière n’existe pas, arrêtez à la fin du cadrage. Quelques jours de travail ont évité un projet de plusieurs mois : c’est un succès, pas un échec, et cela mérite d’être présenté comme tel en comité de direction. Rien n’est perdu, les quatre pages restent valables le jour où la situation change.

Si le rapport est favorable, vous disposez de la base d’un vrai cahier des charges de projet IA : un problème chiffré, un critère de succès, un inventaire de données et un comportement attendu en cas d’erreur. Cadrer un projet IA de cette façon ne garantit pas la réussite, mais cela transforme les mauvaises surprises en décisions prises à temps.

Sources

Laisser un commentaire

Votre commentaire

Jamais publiée, jamais transmise à des tiers.

Les commentaires sont relus avant publication. Voir la politique de confidentialité.