En mai 2015, Dynamics AX n’est plus pour moi un sujet d’observation lointaine: c’est mon quotidien. Comme architecte de solutions chez un joueur de l’industrie du vélo, je vis dans cet ERP, je l’adapte aux besoins de nos dealers, pis je découvre une tension fascinante. Ce gros système d’entreprise, conçu pour structurer les opérations, rencontre de plein fouet le monde de la livraison logicielle moderne. Pis ces deux mondes-là parlent pas la même langue.

D’un côté, l’ERP: rigide, paramétré, pensé pour durer des années sans bouger. De l’autre, la livraison logicielle d’aujourd’hui: livrer souvent, tester, versionner, déployer sans stress. Quand on essaie de moderniser un ERP avec ces pratiques, ça grince.

Deux cultures qui se rencontrent

Le choc, c’est que l’ERP a longtemps vécu en dehors des bonnes pratiques du développement logiciel. On personnalisait directement, sans vrai contrôle de version, sans environnements séparés. Pis ça a marché… jusqu’à ce que ça casse.

flowchart TD
    A[Monde ERP classique] --> B[Personnalisation directe]
    B --> C[Pas de controle de version clair]
    C --> D[Une erreur en prod = panique]
    E[Livraison logicielle moderne] --> F[Code versionne]
    F --> G[Environnements separes:<br/>dev, test, prod]
    G --> H[On teste avant de livrer]
    D -.je veux passer de ceci.-> H

Mon travail, c’est précisément de faire passer Dynamics AX de la culture de gauche à celle de droite. Mettre les personnalisations sous contrôle de version. Séparer les environnements: un pour développer, un pour tester, un pour la production des dealers. Pour qu’une modification soit essayée avant de toucher le vrai monde, pas découverte en plein milieu d’une journée de ventes.

Pourquoi c’est plus dur qu’avec une app web

Un ERP, c’est pas une application web qu’on redéploie en deux minutes. C’est le cœur des opérations: les commandes, les inventaires, la facturation des dealers. On peut pas juste « pousser une nouvelle version » pis voir ce qui arrive. La rigueur de la livraison logicielle devient encore plus importante, justement parce que les conséquences d’une erreur sont énormes.

C’est un mariage de deux prudences. La discipline du logiciel rencontre le sérieux de l’ERP. Pis quand c’est bien fait, on obtient le meilleur des deux: un système central solide, mais qu’on peut faire évoluer sans retenir son souffle à chaque changement.

Mon rôle d’architecte dans tout ça

Ce que j’amène, c’est le pont entre les deux cultures. Convaincre le monde de l’ERP d’adopter le contrôle de version pis les environnements séparés, sans perdre la prudence qui protège les opérations. Pis convaincre le monde du logiciel que non, on ne déploie pas un ERP comme un site web le vendredi soir.

C’est exactement le genre de défi qui m’allume: prendre deux mondes qui se méfient l’un de l’autre, pis bâtir une façon de faire qui respecte les forces de chacun.

Ce que je retiens

En mai 2015, je vis de l’intérieur la rencontre entre Dynamics AX pis la livraison logicielle moderne. Deux cultures, deux rythmes, deux prudences qui doivent apprendre à cohabiter. L’ERP gagne en rigueur — contrôle de version, environnements séparés, tests avant la prod — sans perdre le sérieux qui protège les opérations de nos dealers.

Mon rôle, c’est de construire ce pont. Parce qu’un ERP figé devient vite un fardeau, mais un ERP qu’on modifie n’importe comment devient un danger. Le juste milieu, c’est d’apporter la discipline du logiciel à un système qui en avait grand besoin — pis ça, pour moi, c’est du travail d’architecte au sens le plus concret du terme.