Il y a quelques années, une entreprise industrielle décide de moderniser son ERP. Projet à 18 mois, budget à sept chiffres, intégrateur reconnu. L’équipe IT documente l’existant, liste les fonctionnalités, migre module par module. Livraison dans les temps. Utilisateurs mécontents. Processus toujours aussi lourds, juste sur une nouvelle plateforme.
Ce n’est pas un échec de l’IT. C’est un échec de méthode.
Le symptôme — et comment le reconnaître
“On ne peut pas faire ça. Le système ne le permet pas.”
Si vous avez entendu cette phrase dans votre entreprise, vous connaissez le problème de fond. Vos processus métier se sont progressivement adaptés à vos contraintes IT. Pas l’inverse. Ce qui devait être un outil s’est transformé en référence : c’est le système qui définit comment vous travaillez, pas votre business qui définit ce que le système doit faire.
Le signe le plus révélateur est dans le langage.
J’ai travaillé avec un cabinet de conseil dont tous les collaborateurs parlaient de la “saisie des temps” — une expression qui désignait une seule chose dans leur système. En creusant lors d’un exercice de modélisation, on a découvert qu’elle recouvrait en réalité au moins trois besoins métier distincts.
La RH regardait ces temps pour la paie et la gestion des talents. Le chef de projet les regardait pour piloter la rentabilité de ses contrats. Le directeur des ressources les regardait pour identifier les consultants en sous-charge et rééquilibrer les équipes — décharger ceux en surcharge, valoriser ceux qui avaient de la disponibilité.
Trois usages. Trois granularités. Trois temporalités différentes. Mais comme le système ne connaissait qu’un seul concept, personne n’avait jamais remis en question cette unité artificielle. On a réalisé, en fin d’exercice, que la RH et le directeur des ressources n’avaient pas besoin des mêmes données. Le système les avait maintenus dans l’illusion qu’ils parlaient de la même chose.
Quand votre équipe utilise le vocabulaire de votre système pour décrire votre réalité métier, la contamination est complète.
L’erreur classique des projets de modernisation
Quand une entreprise décide de moderniser, la première question posée est presque toujours la même : “Qu’est-ce qu’on a ?”
On convoque l’équipe IT, on audite l’existant, on liste les fonctionnalités, on cartographie les flux. Puis on demande aux intégrateurs : “Comment on migre ça ?”
Le résultat est prévisible : un nouveau système qui reproduit l’organisation de l’ancien. Nouvelle stack, mêmes contraintes. Nouveau contrat, même frustration. Le budget a été dépensé, le projet a été livré — mais le problème de fond n’a pas été posé.
Partir de l’existant pour définir le futur, c’est garantir que le futur ressemble à l’existant.
Problem space et solution space — la distinction qui change tout
Il y a deux questions fondamentalement différentes dans un projet de modernisation.
La première : qu’est-ce que votre business a réellement besoin de faire ? Quelles sont vos règles métier réelles — celles qui viennent de vos contraintes réglementaires, de votre chaîne de valeur, de vos clients ? Indépendamment de comment votre SI actuel fonctionne.
C’est ce qu’on appelle le problem space : la réalité de votre domaine métier, libérée de toute contrainte technique. La “saisie des temps” n’existe pas dans le problem space. Il y a la gestion de la paie, le pilotage contractuel, et l’allocation des ressources — trois concepts distincts, avec leurs propres règles, leurs propres acteurs, leurs propres besoins de données.
La seconde : comment la technologie va servir cette réalité ? Avec quels systèmes, quelles intégrations, quelles contraintes de budget et de faisabilité ? C’est le solution space : l’architecture cible, avec ses compromis réalistes.
La séquence est non-négociable. Problem space d’abord. Solution space ensuite. L’inverse produit des systèmes qui perpétuent la confusion plutôt que de la résoudre.
Pourquoi la séquence est presque toujours inversée
Les équipes IT partent de ce qu’elles connaissent. C’est humain. Documenter l’existant est tangible, rassurant, facturable. Modéliser ce que l’entreprise devrait faire — indépendamment de ce qu’elle fait aujourd’hui — est inconfortable, et souvent perçu comme théorique.
Les prestataires ne sont pas incités à poser cette question. Ils sont mandatés pour livrer un système, pas pour remettre en cause les besoins. Plus l’existant est complexe, plus la migration est chère.
Et le business lui-même a du mal à formuler ses besoins en dehors de ses contraintes actuelles. Quand on demande à un directeur des opérations “comment devrait fonctionner votre processus idéalement ?”, la réponse commence presque toujours par “actuellement, ce qu’on fait c’est…”. Le domaine métier n’a jamais été formalisé. Il est logé dans les habitudes, dans les contournements, dans les formations internes. Et dans le vocabulaire du système.
Ce que ça change en pratique
J’ai travaillé sur un projet de modernisation où on a consacré trois mois à modéliser le domaine métier avant de toucher à l’existant. Trois mois qui ont failli être supprimés du planning à chaque comité de pilotage. “On perd du temps.”
Ce qu’on a découvert : une partie significative des “contraintes” que l’équipe IT considérait comme des données du problème étaient en réalité des règles business jamais formalisées — parfois contredites par les pratiques réelles des équipes terrain. Des cas d’usage entiers invisibles dans le système actuel, non pas parce qu’ils n’existaient pas, mais parce qu’ils avaient été contournés si longtemps qu’ils étaient devenus de l’implicite.
Le plan de migration final était radicalement différent de ce qu’on aurait produit en partant de l’existant. Moins de modules à migrer. Plus de valeur dans les douze premiers mois. Moins de dette dès le départ.
Modéliser le domaine sans les contraintes du legacy, ce n’est pas une erreur. C’est le prérequis pour savoir quelles contraintes comptent vraiment.
Donc, concrètement
Avant votre prochain projet de modernisation, une question à poser à votre équipe ou à votre prestataire : “Par quoi commencez-vous — par ce qu’on a, ou par ce qu’on a besoin de faire ?”
Si la réponse commence par l’audit de l’existant, le risque est là.
Un projet qui part du domaine métier prend plus de temps au démarrage. Il délivre moins de confusion sur la durée, moins de refontes six mois après le go-live, et un résultat qui sert votre business — pas votre SI de 2014.
C’est la première chose que je fais dans tout Architecture Assessment : modéliser le domaine avant de proposer quoi que ce soit.
Si vous êtes CTO plutôt que CEO et que vous gérez cette discipline sous pression de delivery, cet article traite du piège spécifique qui attend les équipes en cours d’exécution →