Demandez à n'importe quel directeur de programme ce qui a fait dérailler son calendrier de transformation, et les plus honnêtes ne répondront ni la culture, ni le budget, ni même l'éditeur. Ils répondront l'intégration. La nouvelle plateforme fonctionnait parfaitement isolément. Le problème était de la faire communiquer avec les quinze autres systèmes avec lesquels elle devait échanger des données, dont plusieurs avaient été intégrés dix ans plus tôt par des personnes parties depuis, selon des schémas que personne n'a jamais entièrement documentés et que personne ne veut aujourd'hui toucher.
Nous appelons cela la dette d'intégration : le coût accumulé de chaque connexion point à point, cartographie de données non documentée et solution de contournement construite pour faire communiquer deux systèmes sous la pression d'un délai. Comme la dette financière, elle est invisible au bilan jusqu'à ce que l'intérêt tombe, généralement au beau milieu d'un programme de transformation, lorsque l'organisation découvre que modifier un système en casse discrètement trois autres.
Une dette qui s'accumule en silence
La dette d'intégration s'accumule de la même manière que la dette technique, par des décisions raisonnables à court terme que personne ne revisite. Un système financier doit envoyer des données à un outil de reporting, alors quelqu'un construit une connexion directe plutôt que de la faire transiter par une couche d'intégration partagée. Cela fonctionne, cela est livré, et cela est discrètement oublié. Multipliez cette décision par chaque paire de systèmes dans une entreprise de taille moyenne sur une décennie, et vous obtenez un paysage d'intégration qui ressemble moins à une architecture qu'à un plat de spaghetti, chaque fil portant une charge que personne ne peut vraiment expliquer.
Les organisations les plus exposées sont, ironiquement, celles qui ont le mieux réussi. La croissance par acquisition, le lancement rapide de nouveaux produits et des années de solutions ponctuelles achetées pour résoudre des problèmes immédiats laissent tous le même résidu : plus de connexions que quiconque n'en a l'inventaire, et moins de confiance que quiconque ne l'admettra sur ce qui se passe si l'une d'elles est touchée.
L'intégration représente généralement la majorité de l'effort d'ingénierie réel dans une transformation. La budgéter comme une réflexion après coup, c'est ainsi que les calendriers doublent discrètement.
Pourquoi elle devient le plafond du changement
La dette d'intégration n'arrête généralement pas une transformation d'un seul coup. Elle la ralentit, discrètement et de manière répétée, à chaque étape où une nouvelle capacité doit se connecter au parc existant. Les calendriers s'étirent parce que personne ne peut dire avec certitude ce qui va casser. Les budgets gonflent parce qu'un travail d'intégration estimé à deux semaines se révèle nécessiter de rétro-concevoir une interface non documentée construite dans un système remontant à trois éditeurs en arrière.
Le schéma que nous observons le plus souvent est un programme de transformation qui budgète soigneusement la nouvelle capacité et presque pas du tout le travail d'intégration nécessaire pour la connecter à tout le reste. L'intégration est traitée comme de la plomberie, un détail à régler pendant la mise en œuvre plutôt qu'une décision de conception de premier ordre prise en amont. C'est précisément l'inverse : dans un parc technologique mature, l'intégration représente généralement la majorité de l'effort d'ingénierie réel, et non une réflexion après coup greffée dessus.
- ·Maintenir un inventaire vivant des intégrations, pas un schéma dessiné une fois et jamais mis à jour
- ·Traiter chaque nouvelle connexion point à point comme une décision nécessitant validation, pas un défaut
- ·Financer une couche d'intégration comme un produit avec un responsable, pas un projet qui s'arrête à la mise en service
- ·Retirer délibérément les anciennes connexions plutôt que de les laisser tourner sans surveillance
Traiter l'intégration comme un produit
Les organisations qui gèrent bien cela ont cessé de considérer l'intégration comme une tâche au sein d'un projet et ont commencé à la traiter comme un produit à part entière, avec un responsable, une feuille de route et un budget qui persiste entre les programmes de transformation plutôt que d'être réinventé à chaque fois. Ce simple changement d'état d'esprit modifie presque tout en aval : les intégrations sont documentées parce que quelqu'un en est responsable, les schémas sont réutilisés parce que quelqu'un a la charge d'en tenir un catalogue, et les nouvelles connexions sont examinées plutôt qu'ajoutées de manière ad hoc sous la pression d'un délai.
Cela n'exige pas un investissement de plateforme colossal avant que quoi que ce soit d'autre puisse avancer. Cela exige une décision selon laquelle le travail d'intégration est visible, porté et financé en continu, et un effort modeste mais constant pour rembourser les connexions les plus anciennes et les plus risquées avant qu'elles ne deviennent la raison pour laquelle un futur programme prend six mois de retard.
Rembourser sans arrêter l'activité
Personne n'a le luxe de suspendre les opérations pour réparer la couche d'intégration isolément. La voie pratique consiste à rembourser la dette de manière opportuniste, en retirant ou en documentant les connexions les plus risquées chaque fois qu'un système lié est touché pour une autre raison, et à exiger que toute nouvelle initiative de transformation inclue une véritable évaluation d'intégration avant que son calendrier ne soit fixé, et non après qu'il ait dérapé.
Fait de manière constante, cela transforme l'intégration d'une surprise récurrente en un coût connu et gérable de l'activité. Laissée sans gestion, elle devient la taxe silencieuse que paie chaque future transformation, généralement sans que personne ne comprenne vraiment pourquoi l'estimation s'est encore trompée.
Si vos trois derniers programmes de transformation ont tous dérapé pour des raisons remontant à un travail d'intégration imprévu, ce n'est pas la malchance. C'est un passif non géré qui continue de présenter la même facture, et il continuera de le faire jusqu'à ce que quelqu'un en soit responsable entre les projets, et pas seulement au sein de chacun d'eux.