En septembre 2014, je reste un observateur du monde des ERP — ces gros systèmes d’entreprise qui m’intriguent même si je travaille pas dedans. Cette fois, l’angle qui m’accroche, c’est la tension entre le processus parfait sur papier pis la réalité du terrain. Parce que c’est beau de structurer les opérations, mais quelqu’un, quelque part, doit vivre avec cette structure tous les jours. Pis souvent, c’est là que le bât blesse.

Le sujet me parle parce qu’il dépasse l’ERP. C’est une leçon sur l’écart entre une belle idée pensée en réunion pis sa valeur réelle une fois rendue dans les mains du monde qui fait la job.

La rigidité qui déplace la charge

Un système rigide a l’air de mettre de l’ordre. Mais souvent, il déplace simplement le désordre ailleurs: sur les épaules des gens qui doivent contourner ses limites.

flowchart TD
    A[Processus rigide] --> B[Cas standard:<br/>tout va bien]
    A --> C[Cas réel particulier]
    C --> D[Le système refuse]
    D --> E[L'employé contourne]
    E --> F[Double saisie, fichier Excel<br/>à côté, bidouille]
    F --> G[La charge retombe<br/>sur l'humain]

C’est ce phénomène-là que je trouve révélateur. Quand un système refuse une situation pourtant légitime — un cas particulier, une exception du vrai monde — l’employé invente un détour. Un fichier Excel sur le côté, une note manuscrite, une bidouille. Le processus paraît propre dans le logiciel, mais la vraie complexité a juste déménagé dans l’ombre, sur le dos du monde.

Pourquoi ça arrive presque toujours

La cause, à mon avis, c’est qu’on conçoit pour le cas idéal pis qu’on oublie que la réalité est pleine d’exceptions. Le terrain est toujours plus tordu que le diagramme.

Aucun système peut prévoir toutes les exceptions, c’est sûr. Mais le piège, c’est de prétendre qu’elles existent pas. Un bon système laisse de la place pour le cas particulier. Un mauvais système fait semblant que le monde est aussi propre que son diagramme — pis force les humains à payer la différence.

La leçon que je garde pour mes projets

Même comme architecte web, cette observation me suit partout. Le plus beau processus du monde vaut rien si les gens qui le vivent doivent le contourner pour faire leur job. La rigidité, c’est pas de la rigueur. La vraie rigueur, c’est de comprendre le terrain assez bien pour concevoir un système qui plie sans casser.

Ce que les ERP m’enseignent de loin, c’est l’humilité. Faut écouter le monde qui fait le travail avant de leur imposer une structure. Sinon, on construit quelque chose qui a l’air parfait dans une présentation, pis qui rend la vie misérable dès qu’on referme le PowerPoint.

Ce que je retiens

En septembre 2014, je note que la rigidité d’un système d’entreprise, c’est rarement une vertu en soi. Quand le processus refuse de plier devant les exceptions du vrai monde, il déplace simplement la charge sur les gens du terrain, qui inventent des détours pour survivre.

Je garde ça comme un principe de conception qui dépasse les ERP: un système doit servir les gens qui l’utilisent, pas l’inverse. Pis pour ça, faut commencer par les écouter, eux autres, avant de dessiner quoi que ce soit. La meilleure architecture du monde reste théorique tant qu’elle a pas survécu au frottement du quotidien de ceux qui font la job pour vrai.