Beaucoup de projets IA commencent par la question des outils : quel assistant, quelle plateforme, quel modèle. C'est la mauvaise entrée. Un outil ne sert à rien s'il ne répond pas à un processus précis, sur des données disponibles, avec des personnes prêtes à changer leur manière de travailler. Un diagnostic remet ces questions dans le bon ordre.

Le piège de l'outil d'abord#

Lorsque la direction commence par l'outil, trois problèmes apparaissent presque toujours. Le périmètre se décide par défaut, selon ce que l'éditeur propose. Les priorités suivent les démonstrations, pas les enjeux réels. Et les résultats sont jugés sur l'impression générale, faute de point de départ mesuré.

Le diagnostic inverse cette logique. Il part des processus, pas des outils.

Ce qu'un diagnostic regarde#

Un diagnostic utile couvre quatre dimensions.

Les processus. Où le temps est-il passé ? Quelles tâches se répètent ? Où les décisions bloquent-elles ? Le diagnostic observe le fonctionnement réel, pas l'organigramme ni la procédure écrite.

Les données. Quelles informations existent, sous quelle forme, dans quel système, et qui en a la maîtrise ? Une donnée inaccessible ou non fiable ne peut pas soutenir un cas d'usage.

Les décisions. Qui décide de quoi, sur la base de quelles informations, et à quelle fréquence ? L'IA est utile là où une décision s'appuie sur une lecture longue ou répétitive de documents.

Les compétences et les habitudes. Qui utilise déjà l'IA, et comment ? Quels freins existent ? Un diagnostic ne se limite pas à la technique : il mesure aussi la capacité de l'organisation à adopter un changement.

Les livrables à exiger#

Un diagnostic sérieux produit des documents concrets. Demandez au minimum :

  • une cartographie des processus étudiés, avec les points de friction identifiés ;
  • un inventaire des données disponibles et de leur qualité ;
  • une liste de candidats cas d'usage, chacun décrit en quelques lignes ;
  • une évaluation des risques, notamment sur les données sensibles et la conformité ;
  • une recommandation sur l'ordre de traitement.

Si le prestataire ne peut pas montrer à quoi ressemble ce type de livrable, interrogez sa méthode.

Ce que le diagnostic ne promet pas#

Un diagnostic honnête ne promet pas de gains chiffrés. Il identifie des pistes et leurs conditions. Les objectifs quantifiés se fixent ensuite, à partir d'une situation de départ mesurée. Méfiez-vous de toute proposition qui annonce des résultats avant d'avoir observé vos processus.

La durée se fixe au cadrage#

La durée d'un diagnostic dépend du périmètre : nombre de processus, de services et de systèmes concernés. Elle se définit au moment du cadrage, avec un périmètre écrit. Un périmètre flou produit un diagnostic flou, quelle que soit la durée.

De la priorisation au plan#

Le diagnostic produit une liste de candidats. La priorisation les classe selon trois critères : la valeur attendue, la faisabilité technique et le risque. Le plan d'implémentation s'appuie sur ce classement. Il organise ensuite les premiers cas d'usage, la gouvernance, puis le déploiement et la formation.

Les questions à poser à un prestataire#

  • Quels processus allez-vous observer, et avec quelles personnes ?
  • Quelles données devrons-nous rendre accessibles, et sous quelle forme ?
  • Quels livrables recevrons-nous à la fin du diagnostic ?
  • Comment les candidats cas d'usage seront-ils priorisés ?
  • Quelles sont les limites de votre approche ?

La qualité de ces réponses en dit souvent plus que la présentation commerciale.

Ce qu'il faut retenir#

Le diagnostic n'est pas une étape administrative avant le projet. C'est la partie du projet qui évite de dépenser du temps et de l'argent sur les mauvais sujets. Il donne aussi au dirigeant une base solide pour décider.

Pour aller plus loin#