Méthodologie projet IA : quatre étapes pour décider sur des faits.

Le diagnostic ouvre la conduite de projet IA. Pendant deux semaines, nous regardons un processus avec celles et ceux qui l’exécutent : entrée d’une demande, recherche d’information, exception, validation, sortie. Un entretien avec le seul sponsor ne suffit pas à comprendre les raccourcis utiles ni les cas qui bloquent.

Nous examinons les outils disponibles, la qualité des données et les droits d’accès nécessaires. Cette étape distingue une tâche que l’IA peut assister d’une tâche qui appelle seulement une règle métier mieux écrite ou une automatisation classique.

• Une cartographie décrit le flux étudié, ses acteurs et ses points de contrôle.
• Une liste priorisée rapproche chaque cas d’usage de ses données, de ses risques et de son intérêt attendu.
• Une recommandation explique s’il faut construire, acheter, expérimenter ou attendre.

Le diagnostic peut se conclure sans développement. C’est approprié lorsque les données ne sont pas accessibles, lorsque le volume ne justifie pas un projet ou quand une solution existante répond déjà au besoin. Pour un sujet plus large, il constitue le socle d’un audit IA ; pour un besoin ciblé, il évite de demander trop tôt un devis de production.

La phase de prototype transforme une intention en test utile. Nous fixons d’abord un critère de réussite compréhensible par le métier : une réponse correctement sourcée, un document extrait sans champ critique manquant, une demande orientée vers la bonne équipe ou un temps de préparation réduit. Le critère est écrit avant le prototype, avec les exemples qui servent à le vérifier.

Le prototype travaille sur des données et des situations représentatives, y compris des dossiers incomplets, des formulations ambiguës et des exceptions connues. Il ne vise pas à impressionner lors d’une démonstration ; il sert à révéler ce que la solution ne sait pas encore faire.

• Le seuil attendu est validé par écrit avec la personne qui acceptera la recette.
• Les équipes métier testent le prototype et annotent ses erreurs plutôt que de les contourner.
• Le chiffrage de la mise en production reprend les intégrations, tests et garde-fous réellement nécessaires.

La phase de prototype peut conclure qu’un chatbot fondé sur vos documents suffit, ou qu’une automatisation IA est plus fiable qu’un agent. Cette conclusion réduit le périmètre, mais augmente la pertinence de l’investissement.

Le développement comprend l’intégration et la mise en production. Nous le découpons en fonctions complètes : une étape utilisable est montrée, testée sur le parcours convenu, puis corrigée avant d’étendre le périmètre. Cela évite de découvrir les contraintes d’un ERP, d’une API ou d’un rôle utilisateur à la veille du lancement.

Une solution IA n’est pas seulement un modèle et une interface. Elle doit lire les bonnes données, limiter ses actions, conserver les preuves utiles et reprendre la main vers une personne lorsque le niveau de confiance ou la règle métier l’exige.

• Les accès suivent le principe du moindre privilège et sont testés selon les profils réels.
• Les scénarios de recette incluent les erreurs attendues, les refus et les retours arrière.
• Le dépôt, la documentation technique et les accès remis sont identifiés dans les livrables.

Les utilisateurs participent aux démonstrations et reçoivent une formation sur le parcours livré, pas une présentation générique. Pour un agent IA, cette formation précise également quelles actions restent soumises à validation humaine.

La mise en production ne clôt pas le cycle de vie projet IA. Pendant le suivi, nous observons les résultats réels : qualité des sorties, corrections humaines, demandes rejetées, incidents, coût d’usage par tâche et évolution des volumes. Un tableau permet d’examiner ces éléments dans le temps plutôt que de se fier à une impression après quelques jours.

Une correction n’a pas toutes les mêmes conséquences. Une réponse insuffisamment sourcée peut conduire à enrichir une base documentaire ; une action erronée peut conduire à réduire temporairement l’autonomie de l’agent ; un coût inhabituel peut justifier une limite d’usage ou une architecture différente.

• La maintenance corrige les défauts, les dépendances et les changements d’interface.
• Les évolutions sont priorisées à partir des usages et des retours documentés.
• Un point périodique examine les indicateurs, les risques et les décisions à prendre.

Le service de TMA et maintenance couvre ce travail applicatif. Le calculateur de ROI peut donner une hypothèse de départ ; les données de suivi servent ensuite à la confronter au fonctionnement observé.

La gouvernance ne consiste pas à multiplier les comités. Elle rend chaque décision attribuable. Un propriétaire métier arbitre la priorité et accepte la recette. Un référent technique organise les accès, les interfaces et les environnements. Les personnes responsables des données, de la sécurité, du juridique ou des achats interviennent lorsque leur domaine est touché.

Au démarrage, nous consignons la finalité du système, les personnes concernées, les données utilisées, les actions autorisées et les limites d’autonomie. Au fil du projet, nous ajoutons les décisions de périmètre, les résultats de test et les conditions d’un retour arrière.

• Un registre de décisions évite que les exceptions soient transmises uniquement à l’oral.
• Une recette désigne les données de test, le responsable de validation et les critères de refus.
• Un mécanisme d’escalade précise qui intervient en cas d’incident ou de sortie inhabituelle.

Cette discipline prépare le dossier nécessaire lorsque l’usage présente un risque réglementaire. L’approche sécurité et souveraineté permet de traiter les accès, la journalisation et l’hébergement sans les remettre à la toute fin du projet.

Mesurer ne revient pas à compter les fonctions livrées. Avant le lancement, nous décrivons un point de départ : nombre de demandes, durée de traitement, niveau de reprise manuelle, erreurs identifiées ou délai avant réponse. Après le lancement, le même indicateur est lu avec son contexte : changement de saison, arrivée d’un nouveau canal ou modification d’une procédure.

Un bon indicateur est relié à une décision. Si les réponses validées sans retouche diminuent, il faut déterminer si la documentation est obsolète, si le modèle est mal guidé ou si les demandes ont changé. Si le coût par tâche augmente, il faut savoir s’il suit le volume ou une boucle inutile.

• Les indicateurs de qualité examinent l’exactitude, les sources et les corrections nécessaires.
• Les indicateurs opérationnels suivent les volumes, délais et files d’attente.
• Les indicateurs économiques rapprochent le coût de construction, le coût d’usage et le temps réellement évité.

Nous n’attribuons pas à l’IA un résultat qui dépend d’autres changements. Cette prudence aide à corriger ce qui doit l’être et à faire évoluer le projet sur des preuves, pas sur une promesse initiale.