Face à une demande de transformation IA, le réflexe le plus courant consiste à partir de l'outil : quelle plateforme choisir, quel modèle utiliser, quel prestataire retenir. C'est une question légitime, mais posée trop tôt, elle produit rarement de bonnes réponses — parce qu'elle esquive la question qui devrait venir avant : qu'est-ce qui, concrètement, empêche aujourd'hui cette organisation de créer de la valeur avec l'IA ?
Un diagnostic sérieux commence ailleurs. Sur la qualité et l'accessibilité réelle des données, souvent très en dessous de ce que croient les équipes qui les utilisent au quotidien. Sur la gouvernance : qui a le mandat de décider qu'un cas d'usage passe en production, et qui a le pouvoir de le bloquer sans jamais le dire explicitement. Sur les compétences réellement disponibles en interne, par contraste avec celles qu'on suppose exister parce qu'elles figurent dans un organigramme.
C'est un exercice moins spectaculaire qu'une démonstration d'outil, et c'est précisément pour ça qu'il est souvent sauté. Il demande aussi une rigueur qui n'est pas négociable : les constats doivent être vérifiables, sourcés, pas illustratifs. J'ai vu trop de diagnostics s'appuyer sur des exemples plausibles plutôt que sur des faits vérifiés — ça affaiblit la crédibilité du diagnostic au moment précis où on en a le plus besoin, celui où il faut convaincre un comité de direction de changer une priorité.
Le bénéfice de cet ordre — diagnostiquer, puis seulement après choisir l'outil — n'est pas seulement méthodologique. Il change la nature de la conversation avec la direction : on ne débat plus de la pertinence d'une technologie en général, mais de la résolution d'un problème métier précis, avec un chemin identifié jusqu'à la mise en production. C'est une conversation plus étroite, et c'est justement pour ça qu'elle aboutit plus souvent.