En mai 2016, je constate une chose dans mon travail d’architecte autour de Dynamics AX: la pile d’outils qui entoure l’ERP n’arrête pas de se spécialiser. Avant, l’ERP, c’était presque tout-en-un. Aujourd’hui, autour de lui, il y a un outil pour la gestion de source, un pour les builds, un pour les tests, un pour le déploiement, un pour la surveillance. Chaque outil fait bien sa job — mais les frontières entre eux deviennent plus compliquées à gérer.

C’est une bonne nouvelle pis un casse-tête en même temps. Bonne nouvelle, parce que des outils spécialisés font mieux leur travail qu’un gros couteau suisse mou. Casse-tête, parce que plus il y a de pièces, plus il y a de jointures, pis chaque jointure est un endroit où ça peut accrocher.

La pile qui s’allonge

Quand je dessine ce qui entoure l’ERP de mes dealers aujourd’hui, je vois une chaîne d’outils spécialisés là où il y avait avant un seul environnement.

flowchart TD
    DEV[Développeur pousse<br/>du code] --> SRC[Gestion de source]
    SRC --> B[Build automatisé]
    B --> T{Tests<br/>passent?}
    T -->|Non| DEV
    T -->|Oui| D[Déploiement AX]
    D --> S[Surveillance]
    S -->|Incident| DEV
    S --> OK[En production, stable]

Chaque flèche dans ce diagramme, c’est une frontière. Un endroit où un outil passe le relais à un autre, où un format doit correspondre, où une configuration doit s’aligner. C’est précisément là que mon travail d’architecte se joue: pas dans chaque outil pris isolément, mais dans la façon dont ils se parlent pis se passent le ballon proprement.

Le piège de la spécialisation

Le danger que je surveille, c’est de se retrouver avec une pile tellement spécialisée que plus personne ne comprend l’ensemble. Chaque expert connaît son outil, mais qui voit le portrait complet? Quand une commande d’un dealer suit son chemin de bout en bout, elle traverse toute cette pile. Si une frontière est mal définie, le problème apparaît loin de sa cause.

Le piège classique, c’est qu’un processus ou une pile trop découpée déplace la charge vers les gens qui doivent la faire vivre. Si chaque transition exige une intervention manuelle, on a juste remplacé un gros problème par dix petits. Mon travail, c’est de m’assurer que la spécialisation serve la fluidité, pas qu’elle la complique.

Ce que je retiens

En mai 2016, la pile d’outils autour de Dynamics AX se spécialise, pis c’est globalement une bonne évolution: des outils pointus font mieux leur travail. Mais comme architecte, je sais que la valeur ne se trouve pas dans chaque outil pris à part — elle se trouve dans la qualité des frontières entre eux.

Ma discipline reste la même: garder une carte du flux complet, rendre chaque jointure explicite, pis nommer un responsable à chaque transition. Une pile spécialisée bien gérée, c’est une chaîne fluide. Mal gérée, c’est une collection de silos qui se renvoient la balle. Pour mes dealers, la différence entre les deux, c’est toute la différence entre un système qui aide pis un système qui irrite.