Distinguer les parties pour choisir où intervenir.
Une règle de disponibilité change. Un nouvel outil doit être connecté. Un portail doit présenter une information supplémentaire. Chaque demande semble ciblée, mais elle peut toucher plusieurs parties d’une plateforme.
Pour garder ces interventions compréhensibles, nous organisons Boutik en couches distinctes. L’idée est proche de blocs de construction : savoir quelle pièce remplit quel rôle, comment elle se relie aux autres et où effectuer une adaptation.
Trois couches pour répartir les responsabilités.
La première couche regroupe les mécanismes communs, notamment la détection des changements et le modèle de données. Elle donne une structure partagée aux informations que les autres parties utilisent.
La deuxième adapte cette structure au langage de l’ERP, ou système de gestion intégré. Les noms de champs, les documents et leur organisation varient selon l’environnement. Cette couche traduit les échanges en tenant compte de ce que le système expose et de ce que le projet demande.
La troisième correspond au site ou à l’application que les personnes utilisent. Elle présente les informations et les actions selon leur rôle et leur tâche. Un portail client et un outil interne peuvent avoir des interfaces différentes tout en s’appuyant sur des mécanismes communs.
Les trois couches de conception de Boutik
01Mécanismes communsDétection des changements et modèle de données partagé.
02Adaptation au systèmeTraduction des données et des échanges de l’ERP concerné.
03Site ou applicationInformations et fonctions présentées aux utilisateurs.
Chaque couche peut être configurée, étendue ou remplacée selon le besoin. Les liens entre les couches restent à concevoir, à valider et à entretenir; ce schéma n’indique pas le sens de tous les échanges.
Configurer, étendre ou remplacer : trois décisions différentes.
Configurer consiste à utiliser une possibilité prévue dans la couche concernée. Nous vérifions si ses paramètres permettent de répondre au besoin avant d’ajouter du code. Il faut que la configuration reste compréhensible pour les personnes qui en auront la responsabilité.
Étendre consiste à ajouter un comportement ciblé en conservant le rôle de la couche. Un module peut porter une règle propre à un métier, avec les données et les validations nécessaires. Le périmètre de l’ajout et ses interactions doivent être explicites.
Remplacer devient pertinent lorsqu’une partie ne répond plus au contexte. Cela peut concerner une interface ou une adaptation à un système qui change. La séparation des responsabilités aide à déterminer ce qu’il faut reprendre et ce qui peut être conservé. Elle ne dispense pas de vérifier les effets sur les autres parties.
« C’est configurable, étendable ou remplaçable. » — Philippe Beaulieu
Le cas d’une règle d’inventaire spécialisée.
Pour un distributeur de cordes, nous avons intégré dans un module la distinction entre les longueurs prêtes et celles qui peuvent être fabriquées à partir d’une même matière. Sur le plan de l’architecture, l’enjeu était de donner une place identifiable à cette logique.
Une telle adaptation demande de préciser les données qui entrent dans la règle et l’information qu’elle doit fournir au parcours de commande. L’interface doit ensuite présenter clairement le résultat. En gardant ces rôles visibles, nous pouvons examiner une modification de calcul et une modification d’affichage à leurs endroits respectifs.
L’exemple montre l’intérêt de cibler une intervention. Le module répond à un métier précis; il s’inscrit dans une fondation dont d’autres parties conservent leurs responsabilités. Ce principe peut aussi guider des applications et des automatisations au-delà du commerce.
Les frontières entre les couches doivent être vérifiées.
Dès qu’une donnée passe d’une partie à une autre, il faut s’entendre sur sa signification. Une quantité est-elle prête à livrer ou disponible pour fabriquer? Un statut décrit-il un document reçu ou traité? Les mêmes mots doivent représenter la même situation aux points de passage.
Avant une évolution, nous repérons donc les parcours qui dépendent de la partie modifiée et les cas à revalider. Pour une règle spécialisée, le cas habituel ne suffit pas toujours : une limite de stock, une donnée manquante ou une combinaison de choix peuvent révéler un effet important.
Préparer l’entretien dès la conception.
Un ERP récent ou plus ancien, une application ou un service externe possède ses propres contraintes et évolutions. Nous évaluons les interfaces et les accès disponibles avant de définir la connexion. L’architecture modulaire donne une méthode pour organiser ce travail; chaque environnement garde son analyse à faire.
Il faut aussi documenter les choix : quelle partie porte la règle, pourquoi elle a été adaptée et quels comportements doivent rester valides. Cette connaissance facilite la suite du projet pour le client comme pour les développeurs.
Notre objectif est de pouvoir discuter d’une évolution en comprenant sa portée. La question devient alors concrète : quelle partie change, quelles autres sont concernées et quel travail permet de livrer cette évolution de façon cohérente?
Avant de faire évoluer une partie de la plateforme
✓ Identifier la règle ou l’expérience qui doit changer.
✓ Situer les données, l’adaptation au système et l’interface concernées.
✓ Vérifier si la configuration existante répond au besoin.
✓ Nommer les parcours et les exceptions à revalider.
✓ Documenter la responsabilité de la modification et son entretien.
