En mai 2014, je continue d’observer le monde des gros systèmes d’entreprise de loin — c’est pas mon quotidien, je suis toujours dans le web pis les portails. Mais Dynamics AX revient encore dans mes lectures, pis cette fois un angle m’accroche: la façon dont un ERP force à rapprocher le design pis la livraison. C’est-à-dire l’écart, souvent énorme, entre ce qu’on dessine sur papier pis ce qui se livre vraiment.

C’est un sujet universel qui dépasse l’outil. Dans n’importe quel projet, il y a la belle conception — propre, logique, élégante — pis il y a la réalité de la mise en œuvre, avec ses exceptions, ses cas tordus pis ses « ah, mais nous on fait pas ça comme ça ».

Le fossé classique

Dans bien des projets, le design pis la livraison vivent dans deux mondes séparés. On conçoit dans une salle, on livre dans une autre. Pis entre les deux, il y a un fossé où tombent les malentendus.

flowchart LR
    A[Design sur papier] --> B[Processus propre<br/>et logique]
    B --> C{Rencontre la réalité}
    C --> D[Exception de l'atelier]
    C --> E[Cas particulier client]
    C --> F[Vieille habitude]
    D --> G[Écart design / livraison]
    E --> G
    F --> G

Ce que je trouve intéressant dans le cas d’un ERP, comme observateur, c’est qu’il pardonne pas ce fossé. Un système qui touche la production, les stocks, la finance, ça oblige à descendre dans les détails concrets. Tu peux pas rester dans l’abstrait: à un moment, faut que ça marche pour vrai, avec les vraies règles de la vraie entreprise.

Pourquoi la rigidité force l’honnêteté

C’est là que je vois un paradoxe intéressant. La rigidité d’un ERP, qu’on critique souvent, a un effet secondaire utile: elle force à clarifier ce qu’on laissait flou.

Un système souple laisse vivre les ambiguïtés. Un système rigide, lui, te met le nez dedans: il refuse l’à-peu-près. Pis aussi inconfortable que ce soit, ça oblige les équipes à se parler, à trancher, à aligner ce qui était dessiné avec ce qui sera réellement utilisé. Le design pis la livraison finissent par se rejoindre, pas par vertu, mais par nécessité.

Ce que j’en retire pour mes propres projets

Même si je travaille pas avec Dynamics AX, cette leçon me suit dans mes plateformes web. Le pire ennemi d’un projet, c’est l’écart silencieux entre ce qu’on a conçu pis ce qu’on livre. Plus on tarde à confronter la conception à la réalité du terrain, plus la chute est dure.

Ce que les gros systèmes m’enseignent de loin, c’est la valeur de raccourcir cette boucle. Confronter tôt. Tester contre les vraies exceptions. Refuser de repousser les décisions difficiles. C’est valable pour un ERP, c’est valable pour un portail, c’est valable partout.

Ce que je retiens

En mai 2014, je note que Dynamics AX, comme bien des gros systèmes, a cette qualité cachée: il force à rapprocher le design pis la livraison parce qu’il tolère pas le flou. C’est inconfortable, mais sain. Le fossé entre ce qu’on imagine pis ce qu’on livre, c’est là que meurent la plupart des beaux projets.

Je garde ça comme un rappel utile. La meilleure conception du monde vaut rien tant qu’elle a pas survécu à la rencontre avec la vraie vie. Pis parfois, ça prend un système exigeant pour nous obliger à faire cette rencontre pour de bon.