Je commence l’année comme architecte de solutions chez HLC avec plusieurs écosystèmes à rapprocher, dont Dynamics AX. Une équipe peut livrer une petite fonction en sprint. Lorsque cinq équipes touchent produit, prix, stock et portail, la coordination devient un système en soi.

Le danger est de remplacer chaque dépendance par une réunion. Une dépendance technique possède pourtant des éléments vérifiables : contrat, version, ordre, environnement et propriétaire. Rendre ces éléments visibles réduit davantage le risque qu’un calendrier commun de quarante pages.

Découper une fonction selon les frontières

Prenons l’affichage du stock sur un portail :

1. l’équipe ERP publie un contrat StockDisponible(article, entrepot, quantite, version);
2. l’équipe intégration construit l’API et un simulateur;
3. le portail développe contre ce simulateur;
4. un test de contrat compare fournisseur et consommateur;
5. les données de référence arrivent dans un environnement intégré;
6. un test de bout en bout vérifie un article normal, réservé et absent;
7. le déploiement active la fonction derrière un drapeau.

Les équipes n’attendent pas toutes la même date pour commencer. Elles s’alignent sur le contrat et les exemples. Le simulateur ne remplace pas le test réel; il permet de progresser pendant que la dépendance évolue.

Une équipe plateforme peut fournir pipeline, observabilité et modèles, sans devenir le goulot qui approuve chaque commit. Le produit garde la responsabilité de son service. Les décisions longues à renverser — identité, source de vérité, protocole — passent en revue; le nom d’une classe ne mérite pas un conseil d’architecture.

Mesurer le débit jusqu’à l’utilisateur

Compter les points par équipe encourage l’optimisation locale. Je suivrais le délai entre besoin prêt et usage réel, le temps bloqué, la fréquence de déploiement et les retours. Une fonctionnalité terminée dans quatre équipes mais en attente d’une cinquième n’est pas livrée.

Les branches longues multiplient les conflits. Intégrer souvent, automatiser les tests de contrat et rendre les changements compatibles pendant une transition réduisent le risque. Pour ajouter un champ, on le rend d’abord optionnel, déploie les consommateurs, puis le fournisseur l’exige plus tard. Un changement brutal oblige un déploiement coordonné.

Une panne doit avoir un propriétaire de service et un chemin d’escalade. Le portail peut afficher « stock temporairement indisponible » sans vendre une quantité inventée. Les métriques partagées relient l’expérience aux composants.

Financer la réduction d’une dépendance

Une dépendance répétée ne devrait pas être coordonnée éternellement. Si cinq équipes attendent le même environnement, je réserverais du travail à une API de simulation, des données de test reproductibles ou une capacité de déploiement autonome. Le coût est comparé aux jours bloqués sur plusieurs livraisons. Un graphique de temps d’attente par cause montre où une amélioration de plateforme rembourse le plus. Après le changement, on mesure si les équipes commencent plus tôt et si les défauts d’intégration augmentent. Cette boucle évite de baptiser « gouvernance » une attente structurelle et transforme une douleur interéquipes en investissement avec résultat observable.

Je construirais une carte de dépendances limitée aux prochaines livraisons, avec contrat, date nécessaire et stratégie de simulation. Si une coordination ne change aucune décision ni interface, je l’enlèverais. À grande échelle, l’agilité vient moins de synchroniser tout le monde que de permettre aux équipes de bouger sans se surprendre.