Dans un projet nous avons généralement un grand nombre de parties prenantes, les services métiers qui vont utiliser l’outil, la DSI qui cadre le projet, les prestataires externes qui développent etc…
Nous allons démarrons ici par un sujet qui est au final très simple, évident, mais qui est pourtant rarement mis en oeuvre de manière rigoureuse : l’importance pour toutes ces personnes, ayant chacun leur propre jargon, de parler le même language!
Dans tous les livres qui parlent des concepts que nous présentons ici, ils démarrent tous par la même chose : la définition d’un language universel (ubiquitous language en anglais). C’est à dire simplement chaque fois qu’on identifie un concept dans les discussions, de lui associer un terme précis, unique, que toutes les parties utiliseront systématiquement dans la suite du projet.
C’est tout simplement un glossaire, un document que vous devez établir dès le tout début du projet et qui doit être mis à jour au fur et à mesure que des nouveaux termes sont identifiés ou évoluent. Et c’est d’autant plus important que vous verrez que dans la suite de nos recommandations, nous faisons régulièrement des liens vers le glossaire. Notamment sur le plan technique, nous rappelerons aux développeurs l’importance de nommer dans leur code les variables et les fonctions avec les termes du glossaire, première étape de “l’autodocumentation” qui facilitera considérablement par la suite la maintenance et l’évolution de l’outil.
Donc oui, prenez le glossaire au sérieux et ce dès le démarrage du projet. Vous verrez très vite son impact.
Alors là on va rentre tout de suite dans les sujets où on le sait on ne va se faire que des amis. Mais c’est terriblement important, et si vous lisez ces lignes en étant à la direction générale c’est probablement la partie la plus importante à retenir.
On le constate systématiquement, notamment quand l’outil utilisé par un service a été développé par / sous la supervision de la DSI, nous constatons qu’en cas de problème les services métiers ont tendance à remettre la faute sur l’outil, qui ne serait pas adapté à leur métier, qui ne serait pas ergonomique etc… Ce reflexe nuit considérablement à la réussite du projet, et on ne dit pas ça uniquement pour défendre nos camarades des DSI, mais bien car on le constate : Même si la DSI fait tous les efforts possibles pour comprendre les problématiques métiers, si les services utilisateurs ne s’impliquent pas assez, ne prennent pas en main le projet, alors comment voulez-vous que l’outil correspondent à leurs attentes? Pourtant ils vont laisser en grande partie la DSI prendre les décisions de conceptions, sous prétexte de ne rien comprendre à la technique.
Si le système est frequemment indisponible, alors oui c’est la faute de la DSI. Si le système n’est pas performant, alors oui c’est la faute de la DSI.
Mais si l’outil est inadapté au besoin, alors c’est que le service métier n’a pas mis en place les ressources nécessaire pour s’impliquer dans le projet. Point barre. Si vous estimez que l’outil n’est pas ergonomique, savez-vous préciser en quoi et quelles solutions avez vous proposé pour faciliter votre utilisation quotidienne ?
C’est en tout cas la règle que nous proposons généralement de mettre en place pour bien définir les responsabilités de chacun : les services métiers sont entièrement responsable des processus et des règles qu’ils souhaitent mettre en place, la DSI est là pour executer, accompagner, apporter son expertise technique, cadrer le projet, faire les choix techniques, mais en aucun cas elle ne définie les processus métiers ni n’en est responsable. Si un outil est inadapté, la responsabilité en incombe forcément au service métier.
Et ceci même concernant un logiciel central à l’entreprise (un ERP par exemple), utilisé par plusieurs services métiers et géré essentiellement par la DSI. Dans ce cas, chaque donnée, chaque fichier, est clairement identifiée comme appartenant et géré par un service métier qui prend toutes les décisions concernant celle-ci et est responsable du travail quotidien sur ces données.
Ce principe de base étant posé, nous comprenons bien qu’il reste difficile pour des métiers parfois très éloignés de la technique de s’impliquer dans un projet informatique. C’est pourquoi nous proposons dans les autres sections des approches qui permettent au métier de définir précisemment les processus qu’ils souhaitent mettre en place, essentiellement à travers deux outils :
Nous reparlons plus en détail de ces deux points dans les autres parties, ils constituent le coeur de notre méthodologie. Ils sont également défini par un chef de projet métier, qui est le garant de la bonne expression des besoins du service utilisateur et qui est sous les ordres de celui-ci. Idem nous allons très rapidement en reparler, tant nous estimons son rôle indispensable alors que nous arrivons à obtenir sa présence seulement la moitié du temps.
Nous espérons en attendant avoir tout de même pu vous convaincre de l’importance de bien définir les responsabilités de chacun au démarrage du projet. Dans la partie technique de cette section, plus destinée aux DSI, nous exprimons plus en détail notre méthode de travail, que nous appelons “cartographie stratégique”. Qui vise à modéliser l’ensemble des outils de l’organisation, les services métiers qui en ont la responsabilité, ainsi que les différentes intéractions entre chacun.
Ceux qui connaissent un minimum auront reconnu la méthodologie “Design orienté domaine” (Domain driven design ou DDD en anglais) qui est effectivement au coeur de notre méthodologie et que nous cherchons tout simplement à populariser à travers ce site et les différents outils que nous publierons à l’avenir.
Le DDD est constitué de deux parties : une partie stratégique, qui consiste à cartographier les différents domaines de l’entreprise et comment ils interagissent entre eux, et une partie tactique où l’on rentre beaucoup plus dans le détail de l’implémentation au sein d’un outil.
C’est la partie stratégique qui nous interesse dans ce chapitre. En prenant connaissant de l’architecture d’une nouvelle organisation, nous cherchons dans un premier temps à identifier les différents domaines métiers de l’entreprise. Par exemple la facturation, la comptabilisation, les notes de frais, l’émission des fiches de payes, la formation des collaborateurs, la prospection etc…
Que nous allons ensuite chercher à regrouper dans ce que la méthodologie appelle des “Contextes” (Bounded Context en anglais, pas vraiment de bonnes traductions en français). C’est ces contextes qui définissent les périmètres de responsabilité, par exemple le contexte RH, sous la responsabilité de la DRH, s’occupe de gérer le domaine métier lié à la paye et la formation. Le contexte comptabilité, sous la direction de la direction financière, s’occupe de la facturation, la comptabilisation et les notes de frais, la direction commerciale s’occupe de la prospection etc…
Mais pas seulement. Le plus important en représentant un contexte est de bien faire en sorte qu’il s’agisse d’un bloc dont nous n’avons pas besoin de représenter les interractions internes, car les décisions se prennent très facilement au sein de ce bloc. Ainsi une décision à prendre entre la facturation et la comptabilisation sera plus facile à prendre qu’entre la paye et la comptabilité, où deux services doivent se coordonner. Pour cette raison, il faut aussi prendre en compte les outils qui sont utilisés par chaque contexte, ainsi si la paye et la formation sont gérés dans deux outils différents, il peut être interessant de créer deux contextes différents à cause des difficultés d’intégrations entre les deux outils, le fait qu’ils peuvent être géré par des équipes de développeurs différentes etc. Idem si par exemple on utilise un service externe en SaaS pour les notes de frais, les décisions sont prises par le service comptable mais on est tellement dépendant du fonctionnement du service externe qu’il est préférable de créer un contexte à part.
Ce qui va nous permettre d’arriver à la dernière de cette cartographie, les interactions entre les différents contextes. Notamment les échanges de données. Par exemple la paye qui transfère les informations de salaires à la comptabilité, la prospection qui transfère les informations de nouveaux clients à la facturation etc… Tous ces flux sont des échanges que nous voulons voir apparaitre sur la cartographie.
Et pour chaque échanges, nous voulons également préciser le niveau de coopération entre les contextes. Ils peuvent être de six types :
Ceci est une introduction très rapide à la modélisation stratégique de l’organisation, nous vous encourageons bien entendu à consulter la littérature sur le sujet pour en apprendre plus. Dans la partie suivante nous rentrerons cette fois dans la partie tactique, c’est à dire comment les développeurs peuvent implémenter ces concepts dans le code de l’outil.
On continue avec un autre sujet important qui se retrouve généralement géré par la technique, au lieu d’être totalement supervisé et contrôlé par les services métiers.
Comment les développeurs reçoivent leurs instructions ? Généralement avec des maquettes des différents écrans à créer (c’est bien, mais insuffisant on va le voir), avec en parrallèle un cahier des charges décrivant les différents besoins exprimés par le service utilisateur.
Et à partir de là, les développeurs et le product owner s’enferment dans leur grotte pendant des semaines pour préparer un premier prototype, essayer de trouver une modélisation qui correspond à peu près en espérant que ce sera approuvé par le service utilisateur. Qui fera des remarques mais qui acceptera plus ou moins car au bout d’un moment faut que ça avance.
C’est peu dire que honnetement cette approche n’est pas la plus efficace. Et ça vient essentiellement du fait que pour la majorité des services utilisateurs, modéliser leur fonctionnement via un simple schéma c’est déjà faire de la technique.
Vous avez remarqué à quel point chaque cahier des charges est différent, entre chaque projet ? Peu de méthodologies permettant de modéliser précisemment les processus métiers sont connus même par les product owners. C’est ici que nous intervenons, oui il existe des méthodes, à la portée des services métiers, pour modéliser efficacement leurs attentes.
Ce que nous proposons, et que nous etayons plus dans la partie technique car ça demande quand même d’utiliser certains termes techniques, permet de :
Pour récupérer ces informations il y un atelier qui existe depuis plusieurs années, à faire avec les experts métiers. Il s’agit des ateliers “Event Storming”. Nous n’en faisons pas une présentation complête ici sur le site (pour l’instant), mais vous trouverez facilement des informations sur internet. Dans les très grandes lignes, il s’agit d’inviter les participants à citer chaque évènements provoquant un changement dans leurs données, avant ensuite de les regrouper et de les organiser pour en déduire la modélisation du processus métier qui en découle.
En définissant toutes ces informations en amont, les développeurs n’ont plus de décisions à prendre et peuvent implémenter à la lettre les instructions qu’on leur a donné. Mieux encore, en appliquant des méthodes dont nous parlerons plus tard, il est possible pour eux de structurer leur code de sorte à ce que l’outil lui-même soit capable de générer à tout moment ce schéma du fonctionnement métier.
Permettant ainsi au service utilisateur de contrôler à tout moment comment l’outil fonctionne et de demander par la suite facilement des évolutions.
Dans la partie technique nous rentrons plus dans le détail sur le nom de cette méthodologie, sur les concepts qui l’accompagne et sur comment l’implémenter efficament dans le code de l’outil.
Dans la partie vulgarisation, nous essayons d’ouvrir les yeux aux services métiers sur la quantité de décisions qui sont prises en permanence par les développeurs back-office, qui ne relèvent pourtant en rien de la technique mais qui sont purement des processus métiers qui n’ont pas été suffisamment spécifiés.
Et nous essayons de les convaincre qu’il doivent se réapproprier ces décisions. Néanmoins pour cela il faut aussi que l’outil lui-même puisse se plier aux ordres des experts métiers, et c’est là que nous entrons dans la partie tactique du développement orienté domaine métier.
Le DDD introduit des nouveaux concepts, qui vont plus loin que la simple notion de modèle (un modèle correspondant généralement à une table dans la base de donnée):
Nous n’allons pas forcément présenter ici tous les concepts de la partie tactique du DDD, ce qui faut retenir surtout c’est que la partie domaine métier doit être totalement isolée dans le code de votre application et surtout indépendante de la base de donnée. Nous consacrons toute une partie vulgarisation sur le site à tenter de faire prendre conscience aux profils métiers à quel point la base de données introduit aujourd’hui un biais qui vient corrompre le fonctionnement de leurs processus métiers. Les développeurs doivent isoler dans des packages à part les processus métiers, les règles de gestion, les contraintes de validation, les actions possibles, et des tests unitaires doivent être définis à ce niveau independamment de tout concept technique. Il s’agira du niveau le plus bas de votre application, le package qui n’a aucune dépendance. Idéalement, les experts métiers doivent même potentiellement être capable de lire ce code du domaine métier et pouvoir y apporter des remarques et des suggestions.
Ensuite, par injection de dépendance inversée (via une interface qui aura été définie dans le package du domaine), les développeurs vont insérer le “Repository” qui est le package qui fera le lien avec la base de données. Le domaine sera également appelé par la couche présentation, qui rend le domaine accessible depuis l’extérieur de l’application (API, interface graphique etc.)
Il existe extrêmement peu de frameworks orienté domaine métier malheuresement, c’est pour cela que cette approche reste encore trop méconnue aujourd’hui. Notre rôle n’est pas d’expliquer ici tout ce qu’il y a à savoir sur le DDD, nous vous invitons encore une fois à consulter la littérature sur le sujet. Par contre nous avons bel et bien pour objectif de fournir aux développeurs des frameworks DDD, dans différents languages et même dans la mesure du possible réutilisant des frameworks déjà existants. C’est comme cela que nous pensons apporter notre valeur ajoutée à nos clients, en modélisant leurs processus métiers, puis en les orientant vers des prestataires compétents qui utiliseront les bases techniques que nous leurs aurons fourni.
Cette fois-ci nous n’avons pas forcément de solution magique, de grand principe à énoncer pour soudainement résoudre la difficulté du sujet.
Choisir un fournisseur ou une technologie sur laquelle construire l’outil dépend de l’expérience de chacun, des préférences et des compétences disponibles sur le marché. Sachez néanmoins que nous cherchons à établir de notre coté une expertise sur la question, en établissant une liste de critères sur les sujets les plus récurrents et il s’agit même d’une plateforme que nous prévoyons plus tard de vendre aux services achats. Vous trouverez plus d’informations sur la page de présentation de nos services.
Il y a tout de même quelques informations importantes que nous pouvons partager sur ce sujet, il s’agit de la catégorisation des besoins et comment cela doit influer le choix du type d’outil.
Vous avez trois grands types de besoins :
Générique : Les besoins du service métier sont partagés avec un grand nombre d’autres organisations. On peut notamment citer les logiciels de paye, de comptabilité etc… Dans ce cas, vous avez tout intérêt à prendre un logiciel “sur étagère”, clé en main, qui impose ses processus existants au service métier plutôt que l’inverse. Même si il faut payer des frais de licence, il s’agit généralement du rapport qualité/prix le plus avantageux et a également l’avantage de généralement faire évoluer le quotidien des services métiers vers les bonnes pratiques du secteur. Nous classons également dans cette catégorie tous les services en “SaaS”, où vous louez généralement via un prix par utilisateur un service fourni par un fournisseur.
Coeur : Inversement, un besoin Coeur représente un processus métier qui est directement relié à la valeur ajoutée de votre organisation, à ce que vous apportez à vos clients. Dans ce cas, vous devez vous assurer d’avoir une maitrise complête de la base technique, ne pas être dépendant d’autres organisations, mettre en place une politique qualité pour minimiser les perturbations pour vos clients… Imaginez le système derrière le moteur de recherche de Google, ou le système de paiement sur Amazon, c’est de cela dont on parle. Un système Coeur est existentiel pour organisation, il dispose d’un budget conséquent pour son développement et sa maintenance, il est géré par une équipe interne et dispose d’une forte attention de la direction générale.
Support : Enfin, un besoin Support est un processus métier qui reste un besoin personnalisé de votre organisation, c’est à dire que vous ne pouvez pas juste acheter l’outil sur étagère, aucun ne correspond, mais pour autant il ne s’agit pas non plus d’un besoin existentiel pour votre organisation. Ce qui ne veut pas dire que des perturbations n’ont pas de conséquences, si vous deviez avoir une interruption de service de plusieurs heures le travail des collaborateurs serait impacté, mais vous ne risquez pas des articles de presse parlant de cette panne ou d’entamer la confiance de vos clients. Un besoin Support est généralement géré par une équipe interne, mais peut être sous-traité à un prestataire externe et dispose d’un budget bien plus limité qu’un besoin Coeur. Votre objectif pour cet outil est de limiter au maximum les coûts tout en répondant tout de même aux attentes des services utilisateurs.
Avoir en tête ces trois catégories est important, et vous permettra de définir dès le démarrage du projet dans quel direction orienter vos recherches si un outil sur étagère est pertinent et le budget à allouer au projet si cet outil doit être développé en interne.
Sur ce point nous allons tenter d’expliquer un biais qui est fait par l’immense majorité des développeurs. Il nous semble important de le vulgariser car si on veut changer les choses il faut que la demande vienne vraiment des services utilisateurs eux-mêmes.
Ce biais est comme indiqué dans le titre, lié aux bases de données. Les bases de données sont le moteur au coeur de l’outil qui stocke les données, qui les structure, permet d’y accéder facilement et de gérer des millions ou des milliards d’enregistrements. Son importance est considérable, au point qu’on peut se dire que l’outil n’est souvent qu’une surcouche de la base de données.
Pour illustrer, vous pouvez imaginer une base de données comme un immense fichier Excel, avec des feuilles, des colonnes et des lignes. Chaque feuille correspond à un type de donnée différente, chaque ligne correspond à un enregistrement, chaque colonne à un champ de cet enregistrement. Vous pouvez ensuite faire des recherches sur ce fichier, des tris, des regroupements etc. Simplement ce fichier Excel est centralisé et ne va pas s’écrouler au bout quelques dizaines de milliers de lignes…
Vous devez comprendre que les outils que les développeurs utilisent, les bases techniques, font un lien direct entre l’interface utilisateur que vous voyez et la structure de cette base de donnée. Problème : cette structure “Excel” de la base de donnée ne représente que de manière très imparfaite la modélisation de votre métier. Elle est souvent assez proche certes, mais à cause de cette proximité des informations se perdent sans que personne ne s’en rende vraiment compte.
Imaginez par exemple un fichier Excel avec deux feuilles, l’un avec une ligne par facture et l’autre avec une ligne par ligne de factures. C’est ainsi que l’on programmerait généralement un logiciel de facturation. Le problème, c’est que quand vous faites une action pour modifier une ligne de facture en changeant le prix unitaire du produit vendu, en réalité votre intention c’est de modifier votre facture elle-même car le total de votre facture va également changer. Si vous consultez l’historique de modification de votre facture, vous voulez savoir que le prix unitaire de la ligne de facture à été modifié à tel moment.
Certes le développeur va pour compenser rajouter du code pour gérer ce qui est attendu par l’utilisateur, mais il va du coup rajouter une couche de complexité et c’est précisement cet effort supplémentaire qui provoque généralement des incompréhensions avec le développeur, des retards dans le projet, des écarts avec les attentes des utilisateurs.
Pour résoudre cette situation, le mieux est de pousser les développeurs à utiliser des bases techniques qui sont “orienté domaine métier”. C’est à dire qu’ils doivent d’abord modéliser dans leur code le fonctionnement du métier, sur la base du schéma de la logique métier que nous avons évoqué plus haut, y implémenter toutes les règles de gestion, et seulement après faire le lien avec la base de données qui sera tout de même toujours nécessaire. Mieux encore, en séparant à ce point le code lié au processus métier et le code vraiment “technique”, il devient même possible avec un minimum de formation pour le métier d’être capable de lire le code du développeur et de valider directement tout changement lié au processus métier. C’est en tout cas dans cette direction que nous essayons de vous emmener quand cela est possible.
Ces bases techniques orienté domaine métier sont encore rares et méconnus des développeurs (moins de 5% des outils disponibles pour eux). Cette approche existe pourtant depuis longtemps, elle a été théorisée avant le début des années 2000, est largement documentée dans les livres et une large communauté s’est construite autour d’elle pour en définir les bonnes pratiques. Mais elle ne s’est jamais imposé dans les écoles ni surtout dans les outils connus des développeurs. Nous souhaitons changer cela, et l’une de nos missions est de publier des bases techniques à destination des développeurs pour qu’ils puissent petit à petit migrer vers des modélisations plus efficaces pour représenter les processus métiers.
Vous aurez compris que vous avez aussi votre rôle à jouer. Si vous êtes un service utilisateur, au moment d’évaluer le prestataire qui va faire vos développements, cela vaut vraiment la peine de les questionner sur la base technique qu’il vont utiliser, et si celle-ci est conçu pour être orientée domaine métier.
Les scripts de tests automatisés sont des scénarios qui sont executés systématiquement par les développeurs avant tout changement déployé en production. Ils permettent de simuler les actions des utilisateurs et de valider que l’outil retourne bien les valeurs prévues. Il existe plusieurs types de tests automatisés, ce dont nous parlons ici sont uniquement les tests fonctionnels ou “de bout en bout” (end to end en anglais), qui simulent l’ensemble des actions de l’utilisateur sur l’outil et leurs conséquences. Par opposition aux tests unitaires qui ne testent chacun qu’une toute petite partie du logiciel et sont plutôt sous la responsabilité du développeur (par pitié arrêtez d’utiliser le terme de test unitaires pour parler des tests automatisés de manière générale, ce n’est pas la même chose).
Il s’agit de la protection la plus efficace contre les régressions, c’est à dire un changement dans le logiciel qui constitue une perte de fonctionnalité pour l’utilisateur. Il faut savoir que l’effet papillon est très présent quand on développe, en faisait un changement dans une partie du code on a très vite fait de provoquer un problème de l’autre coté du logiciel sans nous en rendre compte. Les scripts de tests automatisés nous protègent contre ça.
Et bien sûr, avec un lien aussi fort avec la simulation du processus métiers, ces scénarios de tests sont quasiment systématiquement définis par… les développeurs eux-mêmes! Oui vous avez bien lu, les experts métiers ne sont quasiment jamais impliqués dans leur rédaction. Pire encore, avec des projets qui dépassent souvent les budgets et les scripts de tests généralement fait à la fin, ils sont les premiers sacrifiés par les développeurs pour en finir au plus vite, et ne sont jamais livrés. Au prix de la fiabilité du logiciel dans le futur.
Nous pensons évidemment qu’il s’agit d’une mauvaise approche. Pour nous ces scénarios de tests doivent être définis en amont du projet, ou au moins pendant celui-ci, par les experts métiers. Avec le schémas de la logique métier et les maquettes, il s’agit du troisième axe qui permet de verrouiller complètement le cahier des charges du projet et de limiter au maximum les décisions devant être interprété par les developpeurs.
Notamment, en rédigeant les scénarios de test, les experts métiers vont devoir définir précisemment les variables saisies et celles qui sont attendues en retour. Il s’agit là d’un outil d’une précision remarquable, sans aucun besoin de compétence technique, nécessitant une implication de la part du service métier mais dont l’effet se fait immédiatement sentir.
Il s’agit aussi d’un des meilleurs moyen pour cadrer le contrat avec le potentiel prestataire s’occupant des développements. Nous suggèrons notamment de mentionner d’en tenir compte dans les conditions de paiement avec :
Nous pouvons vous assurer qu’avec cette approche, vous recevrez votre outil en temps et en heure, avec un minimum de bugs et surtout correspondant à vos attentes. Et le prestataire, si il est bon, y sera même tout à fait ouvert car il sait très bien que ces contraintes dépendent entièrement de l’implication du service métier pour définir les scénarios de tests. Implication qui est également indispensable pour la réussite du projet, dans l’intérêt de toutes les parties.
Avec une rédaction sérieuse des scénarios de tests, vous obtenez ainsi un partage clair des responsabilités avec le prestataire, vous permettant de réceptionner l’outil dans de bonnes conditions et vous permettant d’établir des conditions saines avec les prestataires travaillant avec vous.
Le chef de projet métier est la personne qui s’occupe de réceptionner les développements et de valider que ceux-ci correspondent bien aux besoins exprimés par le service utilisateur.
Dans notre vision, nous avons du mal à utiliser la notion de product owner qui a plutot un rôle de cadrage du projet et est souvent sous les ordres de la DSI voir du potentiel prestataire.
Or pour nous le chef de projet métier doit impérativement réunir les conditions suivantes :
Lui permettant ainsi d’être l’avocat des utilisateurs, de comprendre leurs besoins. Il n’a pas besoin d’avoir des compétences techniques ni même forcément d’experience en chefferie de projet informatique. Mais il doit parfaitement connaitre le processus métier et savoir l’exprimer.
Il a pour rôle :
Son rôle est absolument crucial, et pourtant c’est un profil que nous avons souvent de grandes difficultés à obtenir. La raison est souvent très simple : le service métier essaye de faire passer ce travail de cadrage du projet sur le budget de la DSI. Nous le disons avec force, cette approche n’est pas possible. Bien sûr la DSI peut apporter son aide en complément, ou faire appel à un prestataire spécialisé en assistance à maitrise d’ouvrage (comme nous!), mais le chef de projet métier est indispensable pour les validations. Il doit soit être un profil recruté pour les besoins du projet, soit un collaborateur déjà en poste à qui on a dégagé du temps pour qu’il occupe ce rôle.
Cette dernière approche est tout à fait valable, mais il faut également comprendre que c’est un profil qui doit être protégé :
Arriver à obtenir un tel profil, dans cette position, dans le projet est difficile c’est le moins qu’on puisse dire. Mais nous avons pu constater encore et encore que lorsque qu’il est présent c’est un vrai atout, en permettant d’obtenir l’implication du service utilisateur nécessaire pour la réussite du projet.
Nous parlons ici des synchronisations au sens communication entre les différents outils utilisés au sein de l’organisation.
C’est à ce niveau que se définit la frontière entre les différents contextes métiers, et où vous devez assurer l’autonomie de chacun pour empecher qu’un service ne devienne dépendant des décisions d’un autre. Pour cela il faut faire attention à respecter deux règles :
Terminaux intelligents et tuyaux stupides (“smart endpoints and dumb pipes” en anglais) : Le code complexe qui gère la synchronisation doit être situé au plus près des outils qui communiquent, tandis qu’un outil qui sert à transférer les données doit être le plus simple possible. Autrement dit : Il faut absolument éviter de centraliser les synchronisations dans un outil de synchronisation, généralement développé et géré par la DSI et qui se retrouve à gérer au même endroit toutes les synchronisations de l’organisation. Ce système devient très rapidement impossible à maintenir, en plus de transférer une charge importante du processus métier sur la responsabilité de la DSI. Et oui, c’est le modèle qu’on retrouve aujourd’hui dans beaucoup trop de grande entreprises, c’est une erreur majeure d’architecture.
Les outils ne doivent pas se connaitre entre eux : De même, il faut éviter autant que possible qu’un outil s’occupe lui-même de synchroniser ses données avec un autre outil. Le code de cet outil devient dépendant de ce qui se passe sur l’autre application, introduisant une dépendance avec l’autre service métier. Et surtout avec le temps et la multiplication des outils, le nombre de ces relations bilatérales augmente de manière exponentielle et devient très difficile à maintenir (le fameux effet spaguetti), chaque synchronisation devant être maintenu à part alors qu’il est possible de mutualiser une grande partie de ces efforts.
Comment faire donc pour respecter ces deux règles ?
Si un outil A doit communiquer des données à d’autres applications, il peut générer un message contenant l’information “X vient de se produire” et l’envoyer dans l’outil de messagerie (les “tuyaux stupides”). Ensuite un script (le “terminal intelligent”) en charge de tenir l’outil B à jour est abonné à cet outil de messagerie, voit le message et va se charger d’interagir avec l’outil B pour mettre à jour ses informations en fonction de ce qui s’est produit sur l’outil A. Ainsi plusieurs outils peuvent écouter ce qui se passe sur l’outil A sans que celui-ci ne sache ce qui est fait des informations. Ce script est uniquement lié à l’outil B, et peut donc être maintenu par une personne n’ayant pas forcément des connaissances sur l’outil A ou le reste de l’infrastructure de l’entreprise. Il a juste besoin de connaitre le format du message attendu.
Si un outil A doit interroger en temps réel un outil B pour obtenir des informations ou executer des actions, un portail API (le “terminal intelligent”) peut être mis à disposition sur ou en amont de l’outil B. L’important c’est que le format de cette API soit “contractualisée”, l’outil ne peut pas changer ce format sans concertation avec les outils utilisateurs. En revanche, derrière cette API il peut évoluer comme il l’entend.
Il faut préciser que le format du message importe peu, ça peut être une API, un fichier plat etc. L’important c’est où se situe l’interprétation du message et le fait que les domaines métiers soient bien autonomes.
A partir de là nous pouvons identifier plusieurs situations:
La synchronisation ponctuelle : Suite à un evenement qui s’est produit sur un outil source, ou une volonté d’un utilisateur d’envoyer les informations sur un autre outil, on génére un message ponctuel qui sera interpreté par le ou les outils destinataires. Ce message est idempotent, c’est à dire qu’il doit pouvoir être renvoyé plusieurs fois et avoir toujours le même effet sur les outils de destination. Parfois le traitement du message par un outil destinataire est automatique ou d’autre fois nécessite une validation de la part d’un utilisateur. Mais dans les deux cas, la responsabilité du traitement de la donnée dépend du service destinataire, qui dispose au moins d’un accès limité à l’outil source et doit contrôler qu’il a bien récupéréré toutes les données.
La synchronisation totale : Ici les données sur les outils de destinations doivent en permanence être égales à celles de l’outil source. La responsabilité de la synchronisation n’est pas sur le service destinataire, mais sur l’équipe qui maintient la synchronisation. Dans ce cas, le script de synchronisation lié à l’outil destinataire va demander à l’outil source une copie complète des données sources, et va les comparer avec celles qui sont dans l’outil de destination avant d’executer si nécessaire les actions de corrections. Cette synchronisation se fait de manière périodique (par exemple toutes les nuits). A noter qu’on peut également avoir en parrallèle une synchronisation ponctuelle, qui va écouter les évenements de l’outil source et mettre à jour les données immédiatement. On a dans ce cas une mise à jour immédiate des données, en plus d’avoir le soir une vérification totale des données pour s’assurer que des écarts innatendus ne se sont pas produits.
Les scripts autonomes des utilisateurs : Jusque là il s’agissait plutôt de scripts mis en place par des personnes ayant des compétences techniques assez poussées. Mais il est aussi possible de mettre à disposition des utilisateurs des outils no-code, pour leur permettre de mettre en place des actions automatiques, pour des besoins simple sans avoir besoin de monter tout un projet. Pour mettre cette pratique en place, la DSI a besoin d’installer au sein de l’organisation un outil adapté qui va venir se connecter aux différentes applications de l’organisation. L’utilisateur, à qui on aura ouvert dans cet outil les droits aux applications/données auxquels il est censé avoir accès, peut alors créer ses propres synchronisation via une interface graphique en toute autonomie et sous sa seule responsabilité.
Les synchronisations sont une problématique importante car il s’agit généralement de besoins très spécifiques à l’organisation, deux organisations qui utilisent deux même outils peuvent avoir tout de même une synchronisation des données totalement différente. La connaissance des besoins métiers est essentielle, nous vous invitons à prendre ce sujet avec beaucoup d’attention et nous aurions tendance à vous recommander de les internaliser autant que possible.
Jusqu’à présent nous avons surtout parlé de la partie opérationnelle de l’outil, c’est à dire comment les données sont saisies, comment elles sont synchronisées entre les différents outils, comment les processus métiers sont modélisés etc.
Nous allons ici évoquer une partie plus stratégique, comment les données ainsi constituées sont récupérées pour être ensuite analysées avant d’être présentées au personnes décisionnaires.
L’histoire de l’évolution des pratiques en terme de reporting est interessante à connaitre :
Dans un premier temps on a eu l’approche ETL (Extract, Transform, Load en anglais) / Entrepôt de donnée (Data Warehouse en anglais): Extraire les données de l’outil opérationnel, les transformer dans un format exploitable comme base pour produire les graphiques, puis les charger dans une nouvelle base de donnée, où les experts métiers vont se connecter avec leurs outils de reporting. Cette approche a rapidement eu ses limites, car c’était les profils techniques (DSI) qui s’occupaient de la transformation des données, profils qui n’étaient pas forcément les mieux placés pour répondre aux besoins des directions métiers et qui étaient plus attendus sur le fonctionnement de l’outil opérationnel. Cela a rapidement engendré des frustrations, des problèmes de communications et des données à disposition pour les rapports très lentes à faire évoluer, là où il est souvent important de pouvoir prendre des décisions rapidement.
Ensuite on a eu l’approche ELT (Extract, Load, Transform en anglais) / Lac de données (Data Lake en anglais) : Là on est partie sur l’extrême inverse, le service opérationnel prend sa base de donnée et l’envoie directement dans une base de donnée dédiée pour le reporting, sans changer son format. Charge ensuite aux experts métiers de transformer ces données pour produire ensuite leurs graphiques. Cette approche a produit de meilleurs résultats pendant longtemps, les experts métiers étant beaucoup plus autonomes. Toutefois ils étaients vulnérables aux changements de données qui pouvaient se produire à tout moment de la part de l’équipe opérationnelle, un rapport pouvait marcher sur une année mais pas sur la suivante etc. La solution n’était pas encore idéale.
Et enfin celle qui est en train de se déployer petit à petit aujourd’hui, le Maillage de données (Data Mesh en anglais) : Il s’agit essentiellement de l’approche ELT, mais une différence majeure qui rappelle ce que nous avons dit sur les synchronisations : Le service opérationnel “contractualise” les données qu’il met à disposition, c’est à dire qu’il s’engage à maintenir ces données dans le même format. Il peut d’ailleurs le faire via une API, mais il est tout à fait libre de juste mettre à disposition dans une base de données, l’important étant que le format de cette base de données ne change pas suivant les évolutions de l’outil producteur. Ensuite ces données sont référencés dans un catalogue central de l’organisation, où chacun des autres services métiers peut venir consulter et trouver les données qui les interessent, pour alimenter leurs outils de reporting et sortir les rapports qu’ils ont besoin au sein de leur service.
Vous l’aurez compris, nous recommandons fortement l’approche du Maillage de données, qui résout la majorité des problématiques qui ont pu se présenter dans l’histoire des analyses de données, et dont l’approche présente des similarités avec les autres concepts que nous avons pu voir dans les autres parties plus dédiés au coté opérationel.