Quand la solution est exprimée avant le besoin #2

Cet article fait partie d'une série dans laquelle je tente de poser les bonnes questions sur l'IA en tant qu'architecte.

Sur les réseaux, il y a une phrase que j’entends de plus en plus souvent, parfois de manière explicite, parfois entre les lignes :

On veut faire de l'IA.

On ne dit pas "on a tel problème", ni "on cherche à améliorer tel point".

Ici on pose la solution avant le besoin.

Parce qu'on l'a peut-être oublié, mais l'IA est une technologie - pas un processus business à mettre en place, contrairement à des concepts tels que "qualification des prospect', "gestion du cycle de vente" ou encore "support client after-sales".

En tant qu’architecte, ce renversement me semble être le problème majeur de la vague actuelle autour de l’IA.

Je m'explique.

Le "pourquoi" avant le "comment"

Historiquement, un projet bien posé commençait par répondre à la question des points de friction.

Qu'est-ce qui ne va pas dans le processus actuel? Qu'est-ce qu'on essaie de corriger ou améliorer?

• un processus trop lent ?

• une décision trop complexe ?

• une incohérence entre outils ?

• un manque de visibilité ?

Arrivait ensuite la technologie, comme une réponse possible aux besoins.

Et on devrait plutôt dire "les technologies" parce que jusqu'à présent je n'ai pas encore rencontré de réponse au besoin qui soit universelle.

Mais ça, c'était avant... Aujourd'hui on fait l'inverse.

La technologie est là, disponible, puissante, tendance, et on cherche ensuite où l'appliquer. Coûte que coûte.

De la conception à la justification

Quand la solution (technologie) arrive avant le besoin (problème), le rôle d'un architecte change radicalement.

On ne lui demande plus de concevoir une réponse au besoin à l'aide d'une certaine technologie.

On lui demande de justifier un choix déjà fait - Et soyons clair, la plupart du temps ce sont des choix politiques, voir financiers qui ont été pris bien avant que l'architecte ne soit sollicité.

Et comme ça doit passer, on va adapter le discours à la réalité telle que le voudrait qu'elle soit et on sélectionne les indicateurs qui vont dans le bon sens.

(note : c'est ce qu'on appelle le biais de confirmation, j'écrirai un article sur le sujet)

Pourquoi cette approche est dangereuse

Décider d'une technologie juste parce qu'elle est là, va poser des soucis au niveau des discussions, des budgets et surtout des attentes.

• les bonnes questions ne seront plus posées - parce qu'elle pourraient entrer en conflit avec la solution choisie.

• les alternatives ne seront pas explorées - parce que de toutes façons, le choix est déjà fait.

• les contraintes métier seront minimisées - parce que de base, on ne s'est même pas préoccupé de ce qu'était le besoin métier.

Alors certes, le projet avance, très vite vu qu'on aura ignoré toute la phase de cadrage technique, mais les fondations du projets seront quant à elle fragiles, voir complètement instables.

Et quand les problèmes apparaissent plus tard — adoption faible, incompréhension métier, effets de bord — il est trop tard pour remettre en cause le point de départ.

Exemple concret

Imaginons une équipe marketing qui décide d’utiliser l’IA pour personnaliser les campagnes emails.

Sur le papier, l'objectif est attractif. Mais est-ce réellement un objectif?

La question essentielle n'est pas posée : Quel est le problème réel aujourd’hui ?

A nouveau, on est parti de la solution, pas du besoin.

Est-ce :

• un taux de clic trop faible qui pourrait s'expliquer par du contenu trop générique?

• une sur-sollicitation des clients par manque d'alignement entre les interactions via les différents canaux?

• un manque de maîtrise du cycle de vie client ?

Sans cette clarification, il est impossible d'apporter une solution à un problème, vu que le problème est inconnu.

Et oui, on peut très bien mettre en place de l'IA même sans ça.

Elle segmentera, personnalisera, optimisera.

Mais qui dit qu'au final elle ne tentera pas d'optimiser une mauvaise stratégie?

Le piège du “ils le font, alors on doit le faire aussi”

Un argument revient souvent pour justifier ce type de démarche :

“On ne peut pas passer à côté.”

Du point de vue de l'architecture, c’est un très mauvais point de départ.

La technologie n'a de sens que si on l'utilise pour évoluer, améliorer, progresser.

Ce qui compte, ce n'est pas de ne pas passer à côté d'une technologie, c’est de ne pas passer à côté :

• d’un problème réel,

• d’une opportunité concrète,

• ou d’un risque mal identifié.

Confondre les deux, c’est accepter que la technologie oriente le business et pas l'inverse.

Conclusion — Conseil aux architectes

Reposer le problème avant la technologie ne signifie pas refuser l’IA. Cela signifie lui donner la place qu'elle est sensée avoir.

Ton schéma de travail devrait ressemble à ceci :

1. la situation actuelle,

2. ce qui ne fonctionne pas,

3. ce qui doit être amélioré,

4. et seulement ensuite : de quelle manière?

Dans ce cadre, l’IA peut être un excellent moyen. Ou pas.

Et les deux orientations sont des décisions valides.

Si tu es architecte et que le sujet de l’IA arrive dans les discussions, pose cette question :

Quel problème existerait encore si l’IA n’existait pas ?

Si personne ne sait répondre, alors le projet n’est pas mûr et le besoin doit être défini en priorité.

La technologie ne doit jamais être un point de départ. Elle doit être une conséquence.

Et le rôle de l’architecte, aujourd'hui plus que jamais, est de veiller à ce que cet ordre soit respecté.