À ce stade, vous avez réussi à structurer votre service, à mettre en place les outils pour automatiser vos actions les plus récurrentes et à acquérir une connaissance approfondie des processus métiers au sein de votre service. Vous avez atteint vos objectifs principaux, c’est déjà un bel accomplissement.

Désormais, il est temps de réfléchir à la manière dont vous pouvez mettre cette structuration à disposition du reste de l’organisation. En effet, il est fort probable que vous ne soyez pas les seuls à avoir besoin des données générées au sein de votre service. En les rendant accessibles, vous allez contribuer à l’affaiblissement de l’effet “silos” que nous évoquions plus tôt et à la mise en place d’une culture de la donnée au sein de votre organisation. De même, vous aurez certainement besoin de données provenant d’autres services pour vos propres besoins, en espérant que ceux-ci soient à un niveau de maturité similaire au vôtre.

Lors de la mise en place de vos outils, vous avez certainement mis en place plusieurs intégrations bilatérales avec d’autres outils importants chez d’autres services. Ce que nous vous proposons désormais est d’aller plus loin, en mettant à disposition de manière proactive vos données au reste de l’organisation. La DSI de votre organisation doit au préalable avoir préparé le terrain (lien vers la page de la DSI) en préparant un catalogue global des données disponibles au sein de l’organisation.

Ce catalogue, consultable par tous, doit permettre à chaque service de savoir quelles données sont disponibles et comment y accéder. Il doit également permettre de savoir qui sont les référents de ces données au sein de l’organisation, afin de pouvoir les solliciter en cas de besoin. Votre objectif à ce stade sera de référencer vos données dans ce catalogue, en précisant les données disponibles, les formats de données, les règles de gestion associées…

Cela peut se présenter sous plusieurs formes :

• Des API, c’est-à-dire des interfaces de programmation où les services pourront se connecter (par exemple via des outils No-Code) pour récupérer les données ou déclencher des actions au sein de votre service.
• Des fichiers de données, que vous pourrez mettre à disposition sur un espace partagé et qui seront mis à jour régulièrement.
• Des tables dans les bases de données, en lecture seule, que les autres services pourront interroger directement.
• Des événements, c’est-à-dire des messages qui sont envoyés lorsque certaines actions sont réalisées au sein de votre service, et auxquels les autres services peuvent souscrire pour être informés.

La forme importe peu, ce sera essentiellement aux autres services de s’adapter. En revanche, de nouvelles obligations apparaissent pour vous, vous devrez désormais vous assurer que les autres services peuvent compter sur vos données de manière fiable, que le système interne que vous avez mis en place est suffisamment robuste pour respecter les engagements que vous aurez décris dans l’annuaire. C’est cela le dernier niveau de maturité : votre capacité à prendre des engagements auprès des autres services de l’organisation.

Ce que vous devrez aussi prendre en compte dans les évolutions de vos outils, en effet vous aurez rapidement fait de modifier une API, une colonne dans une table qui ne voudrait plus dire exactement la même chose etc… Cela vous imposera une nouvelle rigueur dans la gestion de vos outils, et vous devrez vous assurer que vous avez mis en place les bonnes pratiques pour gérer ces évolutions.

De manière générale :

• Tout ce qui est ajout de données est généralement sans risque. Rajouter une colonne dans une table, un champ dans une API, un fichier de données etc… ne pose pas de problème
• En revanche, tout ce qui est suppression de données ou modification de données doit être fait avec précaution. Il est préférable de ne pas supprimer une colonne dans une table, mais d’en rajouter une nouvelle. De même, il est préférable de ne pas modifier le nom d’un champ dans une API, mais de le laisser et d’en rajouter un nouveau. Cela vous permettra de garder la compatibilité avec les autres services qui utilisent vos données en attendant qu’ils puissent s’adapter à la nouvelle version.

Une ancienne information que vous ne voudrez plus maintenir devra être marquée comme dépréciée et notifiée auprès des services utilisateurs. Idéalement, vous devez pouvoir surveiller en temps réel l’utilisation des interfaces que vous mettez à disposition, afin de pouvoir voir les services encore connectés à des données dépréciées afin de pouvoir les supprimer uniquement lorsque vous êtes certains qu’elles ne sont plus utilisées.

Pour plus d’informations sur la mise en place des ces intégrations qui est en soit un sujet très large, nous dédions toute une partie technique à ce sujet.

(rajouter une partie dans l’autre sens sur la mise en place de la couche anti-corruption)