Avant de lancer un projet IA, cadrez-le vraiment

La plupart des projets IA n'échouent pas à cause de la technologie. Ils échouent parce que personne n'a pris le temps, au départ, de répondre à une question simple : quel problème exact cherche-t-on à résoudre ? Cette question paraît évidente. Elle est rarement posée. On arrive trop vite à la solution, au choix de l'outil, au démarrage du POC. On découvre trop tard que le périmètre était mal défini, que les données n'étaient pas disponibles dans le bon format, que les équipes n'avaient pas été impliquées, que le cas d'usage identifié était trop vaste pour être implémenté en conditions réelles. Un cadrage fonctionnel rigoureux, réalisé en amont de tout projet IA, est l'investissement qui évite ces dérives. Ce n'est pas un préalable bureaucratique. C'est la condition pour que le projet qui suit ait une chance d'aboutir.

IAGOUVERNANCE DE PROJETTRANSFORMATIONCADRAGE AMONT

Maxime Wallon

5/21/20264 min temps de lecture

La bonne question avant la bonne solution

Un responsable métier identifie un irritant dans un processus. Sa conclusion arrive souvent très vite : il faut de l'IA pour régler ça. L'intention est légitime. La séquence est mauvaise.

L'IA est une solution. Or, on ne commence pas par la solution. On commence par comprendre le problème avec suffisamment de précision pour savoir si la solution envisagée est réellement la bonne.

Un cadrage fonctionnel pose d'abord les questions suivantes. Quel est l'irritant précis ? Depuis combien de temps existe-t-il, et pourquoi le processus actuel ne le résout pas ? Quelles données sont disponibles, dans quel état, et accessibles à qui ? Qui est impacté dans l'organisation, et dans quelle mesure ? Quels sont les critères de succès, mesurables et réalistes ?

Quand on fait ce travail correctement, trois scénarios distincts émergent systématiquement. Dans le premier, l'IA est effectivement la réponse la plus adaptée au problème identifié. Dans le deuxième, un outil déjà en place peut couvrir le besoin avec une configuration différente, sans investissement supplémentaire. Dans le troisième, le problème est fondamentalement organisationnel : rôles peu clairs, processus non documenté, données non structurées. Aucune technologie ne résout un problème organisationnel.

Ce troisième scénario arrive plus souvent qu'on ne le croit. Non pas parce que les équipes se trompent, mais parce que personne n'a pris le temps de déconstruire l'irritant avant de chercher une solution.

Un cadrage fonctionnel sérieux peut tuer un projet IA. C'est précisément pour ça qu'il faut le réaliser en premier.

L'inventaire de l'existant, avant d'aller chercher du nouveau

Le réflexe est compréhensible : on a un besoin, on cherche un outil qui y répond. On évalue des solutions nouvelles, on compare des éditeurs, on organise des démos. On finit par choisir.

Puis quelqu'un demande si on a regardé ce que Microsoft 365 propose depuis la mise à jour de l'année dernière.

La plupart des éditeurs majeurs ont intégré des fonctionnalités IA à leurs outils au cours des deux dernières années. Microsoft avec Copilot, Salesforce avec Einstein, SAP avec son assistant intégré, les ERP récents avec leurs modules d'automatisation. Ces fonctionnalités sont souvent incluses dans les licences existantes, ou disponibles avec un surcoût marginal par rapport à l'ajout d'une solution externe.

L'organisation qui déploie un outil externe sans avoir inventorié l'existant prend plusieurs risques simultanément. Elle investit sur un déploiement supplémentaire alors qu'elle paie peut-être déjà pour une fonctionnalité équivalente. Elle crée un nouveau silo qui ne s'intègre pas aux outils en place. Elle multiplie les dépendances et les interfaces à maintenir.

Un cadrage fonctionnel sérieux commence donc par un inventaire. Quels outils sont en place ? Quelles fonctionnalités IA y sont disponibles ou activables ? Quelles données sont accessibles depuis ces outils et dans quel état ? Ce travail prend quelques jours. Il permet régulièrement d'éviter des investissements de plusieurs dizaines de milliers d'euros sur des solutions qui feraient moins bien que ce que l'organisation possède déjà.

Ce que le cadrage coûte, et ce que le non-cadrage coûte davantage

La pression d'aller vite est réelle. Les directions veulent des résultats visibles rapidement. Les équipes entendent que les concurrents avancent. Le contexte crée une injonction à l'action immédiate.

Le cadrage est souvent la première chose qu'on sacrifie sur l'autel de la rapidité.

Ce sacrifice est coûteux. Dans les projets qui ont sauté cette étape, on observe les mêmes dérives. Des périmètres qui s'élargissent en cours de route, parce que personne n'avait formalisé ce qui était dans le scope et ce qui ne l'était pas. Des cas d'usage trop vastes pour être implémentés en conditions réelles, qu'on ne découvre qu'au moment de la spécification technique. Des résistances qui surgissent au déploiement, parce qu'on n'a jamais vraiment qualifié les impacts sur les équipes en amont. Des spécifications qui arrivent incomplètes ou contradictoires chez les équipes de développement.

Un POC lancé sans cadrage préalable coûte du temps, de l'argent et de la crédibilité pour démontrer ce qu'une analyse amont aurait établi en quelques semaines.

Les organisations qui investissent sérieusement dans le cadrage fonctionnel ne prennent pas plus de temps pour démarrer leurs projets IA. Elles prennent moins de temps pour les terminer. Elles lancent des projets plus petits, plus ciblés, dont le périmètre est réaliste. Elles obtiennent des résultats concrets là où d'autres accumulent des POC qui ne passent jamais en production.

Conclusion

Le cadrage fonctionnel n'est pas une étape administrative. C'est un acte de gouvernance. C'est la décision de ne pas lancer un projet avant de savoir précisément ce qu'on cherche à faire, avec quoi, pour qui, et dans quelles conditions.

Cette rigueur prend du temps. Elle en fait gagner beaucoup plus.

Ce travail de cadrage, avant tout projet IA, est au cœur de ce que nous accompagnons chez Rakkan.