L'arnaque de la complexité technique : ce qui tue vraiment vos projets Data

Pendant des années, en tant que développeur, j'ai détesté les missions au forfait. Aujourd’hui, avec le recul, je comprends enfin pourquoi.

Le problème n'est pas le prix. Le problème n'est pas le délai. Le problème, c'est que nous planifions pour un "pire" qui est souvent bien plus rose que la réalité du terrain. Quand on signe un forfait, on essaie de verrouiller l'incertitude. Mais on se trompe de cible. On se demande si c'est "dur à coder", alors qu'on devrait se demander si la donnée existe vraiment. Résultat ? On accumule de la dette technique avant même d'avoir écrit la première ligne de code.

1. Votre matrice de priorisation est cassée

Traditionnellement, pour choisir un use-case, on utilise deux axes : la difficulté technique (le temps de dev) et l'impact business (le ROI).

C’est une erreur fondamentale. Cette vision occulte la variable la plus critique de tout projet IA moderne : la friction cognitive liée à l'accès à la connaissance.

On peut coder l'algorithme le plus sophistiqué du monde en trois jours. Mais si pour nourrir cet algorithme, il faut :

• Trois semaines pour obtenir un accès à un dossier SharePoint obscur.
• Quatre jours d'attente pour chaque question posée à un expert métier surchargé.
• Une documentation inexistante ou périmée depuis 2018.

...alors votre projet n'est pas "complexe techniquement", il est opérationnellement mourant. Je pense que la vraie difficulté n'est pas de faire fonctionner le modèle, mais de faire circuler la valeur sans frottement.

2. Le mythe du RAG : Le code est un détail, la donnée est le boss

Prenons l'exemple à la mode : le RAG (Retrieval-Augmented Generation).

Sur le papier, monter un RAG n’est pas exceptionnellement difficile. N'importe quel développeur senior vous le sort en quelques jours. Mais c'est là que le piège du forfait se referme.

Si votre donnée est dans un format illisible, si elle est silotée, ou si personne n’est capable de valider la véracité des sources, votre projet de système agentique va se transformer en un gouffre financier.

Le Quick win se transforme en calvaire parce qu'on a confondu "faisabilité technique" et "disponibilité de la connaissance". Avant de parler d'IA, parlons d'acculturation à la donnée. Si vos parties prenantes ne sont pas prêtes à libérer du temps pour expliquer le métier, aucun forfait ne vous sauvera.

3. Pourquoi nous commencer par l'Executive Summary

On me demande souvent des études de faisabilité qui durent des mois. Ma réponse ? Prenons deux heures.

Le plus dur n'est pas de répondre aux questions, c'est de formaliser les bonnes questions. Voici comment nous hackons la phase de conception pour garantir la scalabilité :

1. L'Executive Summary d'abord : Avant de toucher à la donnée, on s'assoit avec les décideurs. Quelles sont les 3 questions auxquelles ce projet doit répondre pour avoir une valeur business réelle ? Une fois ces questions écrites, vous avez votre conclusion.
2. Le squelette de présentation : Comment allons-nous visualiser ces réponses ? Quels KPIs ? Quels graphiques ? Une fois que vous avez ça, vous avez le plan de votre architecture.
3. Le diagnostic de friction : C'est là qu'on pose les questions qui fâchent. La donnée est où ? Qui détient la vérité ? L'expert est-il disponible ?

Si vous ne pouvez pas répondre à ces trois points, ne lancez pas de dev. Vous ne feriez qu'acheter de la frustration au prix fort.

Synthèse : Arrêtons de fantasmer la tech

La technologie n’est qu’un amplificateur. Si vous amplifiez un processus où la donnée est inaccessible et les experts absents, vous n’obtiendrez qu’un échec plus coûteux.

Le succès d'une stratégie Data & IA ne se mesure pas à la complexité de l'infrastructure, mais à la réduction de la friction cognitive entre l'idée et la mise en production.

L'essentiel à retenir :

• Le "pire" imaginable lors d'un chiffrage est souvent sous-estimé car il ignore les blocages humains.
• Priorisez l'accessibilité de la donnée avant la complexité de l'algorithme.
• Définissez la valeur (l'Executive Summary) avant de définir le code.