Comment cadrer un projet IA

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

Avant de comparer des modèles, des API, des plateformes ou des outils d’automatisation, définissez la décision métier que le projet doit améliorer. La question utile n’est pas « quelle IA est la meilleure ? », mais « quelle décision, tâche ou quel workflow doit devenir plus fiable, plus rapide ou plus facile à gérer ? ». Un modèle peut générer du texte, classifier des informations ou soutenir un processus, mais ces capacités n’ont de valeur que lorsqu’elles sont reliées à une finalité métier précise.

Formulez l’objectif en termes opérationnels. Par exemple, une équipe peut vouloir réduire le temps nécessaire à la préparation d’un premier brouillon pour une revue interne, orienter les demandes entrantes vers la bonne file ou identifier les enregistrements nécessitant une attention. Évitez les objectifs qui décrivent une technologie sans conséquence métier, tels que « ajouter un chatbot » ou « utiliser l’IA générative ».

L’objectif doit aussi désigner la personne ou l’équipe responsable d’agir à partir du résultat. Si personne ne possède la décision après que le système a produit un résultat, le projet n’est pas prêt pour une comparaison technologique. Cette clarté précoce évite une incompatibilité fréquente : sélectionner un outil performant pour un workflow insuffisamment défini pour l’utiliser.

Choisissez la limite du workflow

La limite d’un projet décrit où le travail commence, où il se termine et ce qui se passe entre les deux. C’est un choix de conception métier avant d’être un choix technique. Une limite initiale étroite peut faciliter l’identification des entrées, des approbations, des exceptions et des mesures de réussite. Elle facilite aussi la décision de savoir si l’IA est réellement nécessaire, ou si une étape d’automatisation plus simple répondrait à une partie du problème.

Cartographiez le workflow actuel en langage clair. Identifiez le déclencheur, les informations reçues, les étapes manuelles actuelles, les points de décision, les transferts et le résultat final. Identifiez ensuite la partie où une assistance pourrait être utile. L’objectif n’est pas de documenter immédiatement chaque détail ; il s’agit de révéler les hypothèses qui resteraient sinon cachées dans une comparaison de modèles.

Décidez du traitement des exceptions avant de sélectionner une technologie. Les workflows réels comprennent des informations manquantes, des enregistrements contradictoires, des demandes inhabituelles et des situations dans lesquelles le processus normal doit s’arrêter. Si un projet ne peut pas indiquer ce qui se passe dans ces cas, il ne peut pas encore définir les exigences d’un composant IA ou d’une couche d’automatisation.

• Quel événement déclenche le workflow ?
• Quelle étape crée le plus grand retard, la plus forte incohérence ou la plus lourde charge de revue ?
• Quelles informations sont nécessaires pour continuer ?
• Quels cas doivent être escaladés ou arrêtés ?
• Quelle est l’action humaine ou système finale ?

Rendez les données et les garde-fous explicites

Un projet IA utile dépend de données maîtrisées, de garde-fous adaptés et d’un objectif métier explicite. Avant de comparer les technologies, décidez quelles informations peuvent entrer dans le workflow, qui peut y accéder, comment elles seront vérifiées et ce qui doit être exclu. Ce sont des décisions métier et de gouvernance qui déterminent les options techniques viables.

Des données maîtrisées ne consistent pas simplement à collecter plus d’informations. Il s’agit d’identifier les entrées approuvées pour la tâche définie, leur source, leurs limites de qualité et les conditions dans lesquelles elles peuvent être utilisées. Un projet peut devoir distinguer les enregistrements structurés, les documents internes, les contenus soumis par les utilisateurs et les informations qui ne doivent pas être traitées dans le workflow proposé.

La revue humaine doit être conçue comme partie intégrante de l’exploitation, et non ajoutée après le choix d’un outil. Décidez si elle est requise pour chaque résultat, seulement pour certains cas ou à des points de contrôle définis. Décidez aussi qui peut corriger un résultat et comment cette correction affecte le workflow. Ces choix aident les équipes à évaluer si une technologie proposée prend en charge les contrôles prévus.

• Listez les sources de données approuvées et les données exclues.
• Définissez les rôles d’accès pour les entrées, les sorties et les paramètres du workflow.
• Fixez les points de revue et les conditions d’escalade.
• Décidez comment les corrections, dérogations et erreurs seront enregistrées.

Définissez la réussite en production

Les comparaisons technologiques se concentrent souvent sur des démonstrations, mais un projet a besoin d’une mesure en production. Avant de choisir un modèle, décidez quelles preuves montreront que le workflow cadré aide l’objectif métier. La mesure doit être liée à la décision ou au processus défini au départ, et non seulement à la capacité du système à produire un résultat plausible.

La mesure en production peut inclure des signaux opérationnels tels que le temps de réalisation, la charge de revue, la précision de l’orientation par rapport à un contrôle convenu, les taux d’exception ou la proportion de résultats nécessitant une révision. La mesure appropriée dépend du contexte, des systèmes existants et de la qualité des données d’entrée. Elle doit donc être définie avec les personnes responsables du workflow plutôt qu’empruntée comme objectif générique.

Décidez également de la fréquence de revue. Un projet doit permettre d’examiner ce qui se passe après le déploiement, d’identifier les conditions modifiées et de déterminer si le workflow reste adapté à sa finalité. Cela ne constitue pas une promesse de résultat fixe ; cela crée une base pratique pour le suivi et l’ajustement lorsque les éléments observés le justifient.

• Choisissez une mesure principale liée à l’objectif métier.
• Ajoutez un petit ensemble de signaux de sécurité et de qualité.
• Établissez une référence ou une description de l’état actuel lorsque c’est possible.
• Attribuez la responsabilité de l’examen des résultats après le déploiement.

Exemple : trier les demandes entrantes

Exemple : une équipe des opérations reçoit des demandes entrantes via un canal partagé et souhaite un triage plus rapide et plus cohérent. Plutôt que de commencer par comparer des modèles de langage, l’équipe décide d’abord que le projet doit préparer une catégorie et une priorité suggérées pour un réviseur. Le réviseur reste responsable de la décision finale d’orientation.

La limite du workflow commence lorsqu’une demande arrive et se termine lorsqu’un réviseur l’affecte à la file appropriée. Les entrées approuvées sont le texte de la demande et certains champs de référence internes. Les demandes qui contiennent des informations incomplètes ou peu claires sont signalées pour attention manuelle plutôt qu’orientées automatiquement. L’équipe précise aussi que certaines catégories exigent toujours une revue avant toute étape suivante.

La mesure en production n’est pas la « qualité du modèle » de manière abstraite. L’équipe prévoit de vérifier si les suggestions aident les réviseurs à prendre une décision finale d’orientation avec moins d’effort évitable, tout en suivant les corrections, les exceptions et les cas impossibles à classifier. Ce n’est qu’après ces choix que l’équipe peut comparer les technologies par rapport aux exigences pertinentes : traiter les entrées approuvées, soutenir la revue, s’intégrer aux systèmes actuels et permettre la mesure.

• Décision métier : quelle catégorie et quelle priorité un réviseur doit-il considérer ?
• Revue humaine : chaque orientation suggérée est confirmée par un réviseur.
• Maîtrise des données : seuls les champs de demande définis et les références approuvées sont utilisés.
• Mesure : suivre les corrections des réviseurs, les exceptions et le temps du workflow.

Utilisez la comparaison technologique comme filtre final

Une fois les décisions métier clarifiées, la comparaison des modèles devient plus utile et moins distrayante. Évaluez les options par rapport au workflow cadré : peuvent-elles fonctionner avec les données approuvées, soutenir les garde-fous requis, s’intégrer à l’environnement opérationnel existant, permettre la revue humaine et fournir les informations nécessaires à la mesure en production ?

Cet ordre laisse également de la place aux alternatives. La meilleure première mise en œuvre peut combiner des règles simples, une automatisation de workflow et un composant IA, ou révéler qu’une amélioration de processus sans IA doit intervenir en premier. La décision doit suivre le besoin métier et les contrôles, plutôt que de forcer le workflow à correspondre à une technologie choisie.

Victor Laybats propose des services d’ingénierie IA et automatisation depuis Paris. Son site public présente une approche qui va du cadrage au déploiement et au suivi, et publie des conseils pratiques pour cadrer, sécuriser et mesurer les projets d’IA et d’automatisation. Cet article est limité par ce contexte public : il propose une méthode orientée décision pour préparer un projet IA, et non une affirmation sur des modèles particuliers, des résultats ou l’adéquation à chaque organisation. Les résultats dépendent du contexte, des systèmes existants et de la qualité des données d’entrée.

• Comparez uniquement les options qui satisfont les exigences de données et de garde-fous.
• Évaluez les besoins d’intégration et d’exploitation en même temps que les capacités du modèle.
• Confirmez que la revue et la mesure restent réalisables après le déploiement.
• Revoyez le périmètre si la technologie disponible ne peut pas prendre en charge les contrôles requis.