La plupart des consultants se trompent sur la personnalisation, dans les deux sens
Un camp évite le code custom par principe et plie le métier autour du standard. Résultat : un système contre lequel tout le monde travaille, et une couche parallèle de tableurs qui fait le vrai boulot.
L’autre camp construit tout ce qu’on lui demande. Résultat : un système que personne ne peut plus mettre à jour, et une facture de maintenance qui survit à celui qui l’a validée.
Les deux sont le même échec : une règle appliquée à la place d’une décision prise. Nous savons quand il faut construire mille objets et quand il ne faut en construire aucun, et les projets intéressants ont besoin des deux réponses à des endroits différents.
Clarity Before Code n’est pas une préférence pour moins de code
Ça veut dire du code écrit à dessein et bien dimensionné. Parfois c’est rien du tout, parce que le standard le fait déjà et que la demande était en réalité un sujet de formation. Parfois c’est une très grosse application, parce que les règles d’exploitation n’ont réellement aucun équivalent standard.
Nous avons construit l’une des plus grosses applications custom Business Central qui existent, au-delà du millier d’objets AL, et elle encaisse chaque mise à jour mensuelle sans impact. Ce n’est pas une contradiction du principe. C’est le principe : le code existe parce que la règle qu’il porte est réelle, et il est construit pour que la plateforme puisse bouger dessous.
La mesure n’est jamais la quantité de code évitée. C’est de savoir si ce que vous avez écrit est encore vrai, et monte encore proprement de version, trois ans après.
La personnalisation négligente, et comment la reconnaître avant qu’elle parte
Des changements cosmétiques qui existent parce que personne ne voulait avoir la conversation sur le process. Des champs ajoutés pour stocker une donnée sur laquelle personne n’agira jamais. De la logique qui masque l’absence de décision, pour que la décision n’ait jamais à être prise.
Techniquement, ça a l’air très bien le jour de la livraison. Ça échoue sur l’autre axe : personne ne sait nommer la règle métier derrière, donc personne ne peut jamais l’enlever sans risque, et ça s’accumule jusqu’à ce qu’une montée de version devienne un projet.
Nous ne sommes pas anti-personnalisation. Nous sommes contre la négligente, et nous la contesterons pendant la conception plutôt que de vous la facturer en maintenance pendant dix ans.
Une règle qu’on sait nommer tient encore des années après, quand elle est mise à l’épreuve. Sur notre propre Business Central, celle qui interdit au compte rendu client de deviner une ligne avait été posée bien avant le mois où plus de la moitié du document s’est retrouvée sans domaine. C’est là qu’on voit si une personnalisation était réfléchie ou seulement livrée.
Construire pour une plateforme qui se met à jour au calendrier d’un autre
Business Central en ligne livre deux vagues majeures par an et des mises à jour mensuelles, et il ne demande pas la permission. Tout code qui dépend d’internes que Microsoft peut changer a une date de péremption, qu’il fonctionne aujourd’hui ou non.
Concrètement : des événements plutôt que des modifications, aucune dépendance à un comportement non documenté, des extensions qui déclarent honnêtement leurs dépendances, et une base de tests qui vous dit qu’une mise à jour a cassé quelque chose avant que vos utilisateurs ne le découvrent.
C’est ce qui sépare une application qui grandit d’une application qui devient un otage. Le coût de bien faire se paie une fois, en conception. Le coût de mal faire se paie tous les mois, indéfiniment.
Une base de tests n’est pas un label de qualité, c’est un instrument de mesure, et la mesure ne dit jamais ce qu’on attend. Sur une de nos intégrations, le premier test réellement exécuté en CI a montré qu’un seul enregistrement refusé pouvait bloquer toute la session.
À quoi ressemble un développement avec nous
On commence par contester la demande, parce que la demande est rarement le besoin. Si le besoin n’est pas clair, la solution est forcément mauvaise, aussi bien réalisée soit-elle.
Ensuite on cadre ce qui est réellement custom, ce qui est standard, et ce qui ne devrait pas exister. Vous recevez ça par écrit, avec le raisonnement, pour que la décision soit la vôtre et pas la conséquence implicite d’un choix technique.
On est bons, mais on n’est pas télépathes. Soyez clair sur la règle métier et on la construit proprement, une fois.
