Rhapsodies Conseil est un cabinet de conseil à taille humaine et ne peut donc pas se permettre de baser son commerce sur la production de conseil en masse comme peuvent le faire des ESN classiques. Sa philosophie est donc de produire une offre « sur mesure » pour ses clients et cela se retrouve dans sa manière de faire du commerce.
Rhapsodies Conseil comme un tailleur
Le terme de « sur mesure » vient du monde de l’habillement classique pour homme. Un costume sur mesure veut dire que le patron est fait à partir des mensurations (besoins) du client et que les détails sont choisis par celui-ci.
Lorsque vous allez vous faire faire un costume sur Savile Row en Angleterre, le tailleur qui allait prendre vos mesures vous faisait parler pour bien comprendre ce qu’il vous fallait (quel type d’événement, ville / campagne, température, …). Le but de tout cela était de s’assurer que le costume réponde bien à votre besoin. Une fois cela terminé, il griffonnait le mot « BESPOKE » sur la liasse de tissu que vous aviez choisie pour la réserver et pour dire que le client avait parlé.
Le commerce chez Rhapsodies Conseil fonctionne de la même manière. Bien sûr, il nous arrive de répondre à des appels d’offres sur des besoins déjà formalisés ou de fournir un CV pour une demande d’assistance avec des compétences attendues spécifiques mais dans tous les cas, la valeur du Cabinet se situe dans sa capacité d’écoute de ses clients. Cela nous permet d’ajuster notre proposition au « juste » besoin du Client. Ce principe de frugalité a été résumé ainsi par un ancien client : “Je ne veux pas que l’on me propose une Ferrari quand j’ai besoin d’une 4L”. En d’autres termes, les facteurs limitants doivent être pris en compte lorsque l’on mène une mission de conseil (temps, budget, besoins, …).
Construire de la confiance
Quand ce dialogue se met en place, une relation de proximité avec le client peut se créer et cette proximité est nécessaire pour connaître l’objectif derrière l’objectif.
Avec votre tailleur, la confiance va vous aider à lui avouer que vous voulez apparaître plus grand, il va donc monter l’emplacement de votre cran, ou que vous voulez avoir l’air plus statutaire, il va alors élargir vos revers… Pour Rhapsodies Conseil, c’est la même chose.
Et pour construire cette confiance, cela se fait plus facilement quand la mission se passe bien mais ce n’est évidemment pas toujours le cas. Plus la relation va durer, plus la probabilité de rencontrer un obstacle augmente et, dans ce cas, il est essentiel d’assumer les erreurs qui ont pu être faites et de les réparer. Le droit à l’erreur existe mais il faut tout faire pour que cela n’arrive plus.
On peut dire que la relation est de confiance quand elle est construite sur 2 niveaux de relation : Le premier niveau est évidemment celui du consultant qui mène la prestation. C’est la qualité de sa prestation qui est la première étape (ou le premier coup de ciseaux dans le cas de notre tailleur) dans la construction de la confiance. Mais que se passe-t-il si le consultant quitte le cabinet ? Après tout, cela arrive dans une évolution de carrière, surtout quand on valorise votre travail. Et bien comme notre tailleur ne travaille pas tout seul (il y a celui qui travaille sur le patronage, celui qui coupe, celui qui confectionne, parfois vous avez un pantalonnier).
Chez Rhapsodies Conseil c’est la même chose : Un consultant n’est jamais laissé seul en mission. Il a toujours accès aux connaissances acquises par le cabinet. Un client ne consomme pas la prestation d’un consultant mais bien celle du cabinet dans son entièreté. Et cette relation passe donc également par un deuxième niveau, le manager de mission. Son rôle n’est pas que de faire le suivi du consultant mais également de prendre du recul sur la mission, échanger sur ses besoins avec le client, comprendre ses contraintes et apporter son point de vue. Quand tout cela est réussi, nous pouvons être sûr que si un des deux niveaux est défaillant, le lien n’est jamais rompu.
Une interaction biologique
Enfin, le but de chaque relation est qu’elle soit bénéfique à toutes les contreparties. Et pour que cela soit le cas, elle doit être envisagée comme un partenariat et pas uniquement comme une relation client – fournisseur. L’un apporte ses besoins, de potentiels projets à forte valeur et Rhapsodies Conseil apporte son expertise et son engagement.
Pour changer de notre analogie avec le tailleur, nous pouvons utiliser le concept biologique qui désigne un processus impliquant des échanges ou relations réciproques entre plusieurs éléments. Il y a bien évidemment un échange, qui est contractualisé, une expertise contre rémunération mais cela ne doit pas être uniquement cela. Pour le client, il faut aussi qu’il puisse intégrer une partie de cette expertise, que les connaissances dont il a besoin soient acquises par ses équipes. Pour le cabinet de conseil, l’intérêt est de confronter le consultant à des problématiques qu’il n’a jamais rencontrées auparavant (nouveau domaine d’activité, nouveau domaine fonctionnel, nouvelle technologie, …) et ainsi élargir le champ de ses compétences.
Existe-t-il une durée de relation idéale ?
Quand votre garde-robe a atteint une taille nécessaire (ce qui est propre à chacun), ou quand votre budget ne vous le permet pas, il n’est pas dans l’intérêt de votre tailleur de vous faire commander tout de suite de nouveaux vêtements. Il risque de vous lasser, de vous décevoir car vous n’avez plus d’attente, voire de vous braquer.
Si on garde le fil de notre analogie, le risque est le même dans le conseil. Il est indéniable qu’une relation à long terme avec un client est bénéfique : on le connaît de mieux en mieux et l’inverse est aussi vrai, en conséquence nous sommes de plus en plus performants collectivement. Mais une relation à long terme ne veut pas dire être toujours là mais être là quand il en a besoin. Nous disions tout à l’heure que pour qu’une mission de conseil soit une pleine réussite, il faut qu’une partie de l’expertise soit captée par le client, que le client monte en maturité sur le sujet.
Cela ne se fait pas en un claquement de doigts (ou un coup de ciseau). Il faut parfois savoir partir pour (mieux) revenir. Le risque à vouloir toujours être là est de trop s’écarter de son expertise, de ne plus justifier son budget et donc d’abîmer la confiance. La relation entre le client et Rhapsodies Conseil et la relation entre le client et le consultant ont des cycles de vie différents. Si la valeur ajoutée de la relation entre le client et le cabinet augmente avec le temps, nous estimons que la durée de vie de la relation entre le client et un consultant doit être comprise entre 1,5 et 3 ans. C’est le temps nécessaire à un consultant pour comprendre et maîtriser l’environnement du client et pour ce dernier d’en tirer les bénéfices.
Comment définir un prix ?
Comme pour toute relation commerciale (tailleur ou conseil), le prix doit correspondre à la valeur perçue pour que la confiance soit maintenue. Si vous avez l’impression de surpayer un bien ou un service, vous ne serez pas enclin à faire un deuxième achat.
Chez Rhapsodies Conseil nous proposons des prix justes, prix marché, par rapport à l’expertise fournie en regard du besoin. Nous n’essayons pas de faire le plus de marge possible au détriment du client et du collaborateur (car le client attendrait une expertise peut être supérieure à celle du collaborateur et cela le mettrait en difficulté)
En contrepartie, la marge de manœuvre pour des négociations est très faible et parfois inexistante. Il nous arrive de perdre des clients qui cherchent une baisse de prix infondée. La solution serait de faire intervenir des consultants avec une expertise insuffisante pour répondre au besoin du client et nous nous y refusons. Cela nous obligerait à baisser la qualité de service à laquelle nous tenons, au risque d’avoir des « casseroles » chez le client, or il est fondamental pour nous de maintenir la confiance.
Si le client n’a pas le budget nécessaire pour financer notre intervention, nous cherchons alors un moyen de baisser le montant total en travaillant sur la priorisation et ainsi apporter un maximum de valeur et cela le plus rapidement possible. Plutôt que de vouloir traiter 100% du spectre avec un budget insuffisant, nous préférons nous concentrer sur les 80% de fonctionnalités qui représentent souvent l’intégralité des attentes prioritaires venant du métier. Pour cela, notre expertise sur l’agilité est rentrée dans notre ADN et nous aide beaucoup dans la manière de mener nos prestations mais également dans notre commerce.
Rhapsodies Conseil commerce comme il travaille
Finalement, la vision de Rhapsodies du conseil est de ne jamais perdre de vue l’objectif dans ce que nous entreprenons. Que ce soit dans nos prestations ou dans notre commerce, le « quick win » n’est qu’un moyen pour atteindre l’objectif final et non une fin en soi. Nous ne voulons pas mettre en péril l’atteinte de cet objectif pour un contrat de plus courte durée. Votre tailleur vous accompagne au fil du temps en prenant en compte vos évolutions physiques, et Rhapsodies Conseil fait de même en prenant en compte les nouveaux défis à relever.
Je n’ai rien contre vous, mais ça va prendre trop de temps de référencer et de compléter nos applis… Vous avez une ligne d’imputation ?
Chef de projet
C’est surtout un énième référentiel qui ne sera pas tenu à jour : beaucoup d’efforts d’initialisation au départ et pas de récompense à l’arrivée !
Directeur d’un domaine applicatif
Je monterai à bord seulement si on me prouve que ça marche et que les autres ont déjà complété leur part.
Indiana Jones
Damn…
En entendant ces retours, Indiana réalise à quel point le déploiement d’un référentiel d’architecture pour son entreprise d’archéologie ne va pas être chose facile… Surtout auprès des parties prenantes qui devront se charger de compléter les informations sur leurs applications.
L’arrivée d’un référentiel des applications, quel que soit l’usage qui en est fait (Application Portfolio Management, gestion de l’obsolescence, transformation du SI…), est majoritairement vu par les équipes opérationnelles comme une contrainte, en termes de temps, et donc de budget.
Armé de son chapeau fedora d’explorateur intrépide, Indiana se lance sur les eaux sinueuses de la mise en place d’un référentiel d’architecture et de la conduite du changement auprès de ses équipes.
Nous retracerons ses péripéties à travers ce retour d’expérience : que pouvons-nous faire concrètement pour lever les freins et faciliter ainsi le changement et l’acceptation de l’outil ?
Enfilez votre meilleur pantalon cargo et chaussez des boots en cuir confortables (nota bene : vous pouvez exclure le fouet de votre attirail) et… Action !
Pour bien se dérouler, l’expédition doit être bien organisée
Première étape, Indiana part à la recherche de recrues sur lesquelles il pourra compter pour mener à bien sa quête.
La mise en place d’un référentiel d’architecture ne s’effectue pas sans un fort sponsoring de la part de la direction. Ces sponsors seront les plus pertinents pour répondre au « pourquoi » (Simon SINEK, « How great leaders inspire action »), ce fameux adverbe qui, à défaut de nous laisser coi, doit au contraire éclairer les lanternes et permettre aux intéressés comme aux sceptiques de rallier la cause. Ainsi, le directeur du Système d’Information, de l’architecture, des études, voire de la sécurité et des différents pôles applicatifs, semblent tous désignés pour accomplir ce rôle de « parrain » (sorte d’Al Pacino corporate) du projet.
Si nos sponsors semblent désignés d’office, nous aurons besoin d’aventuriers au sein de notre organisation projet, de personnes qui promeuvent la démarche et qui veulent utiliser l’outil. Ils seront de préférence opérationnels ou auront une bonne connaissance des équipes, de leurs besoins et contraintes. Ces aventuriers devront également être capables d’aller vaincre les démons de la réticence et de prendre du recul sur la situation. Ce seront des ambassadeurs du projet : des responsables d’applications, des responsables de pôles, des PMO ou autres fonctions transverses, ou même des personnes qui connaissent peut-être l’entreprise et son SI depuis plus de 20 ans… En bref, ces opérationnels seront nos yeux et nos oreilles pour les remontées terrain, afin de permettre à l’équipe projet référentiel d’architecture de répondre aux attendus et de lever le plus tôt possible les principaux freins au changement.
Armé de cette équipe solide, Indiana est prêt à débuter son expédition auprès des responsables d’applications !
Équipement approprié + capacité d’adaptation = le kit du bon aventurier
Qui dit déploiement d’un nouvel outil dit nécessairement conduite du changement auprès des populations concernées. En l’occurrence, si nous arrivons avec un outil qui est vu comme une contrainte, il sera important d’adapter nos leviers à notre public. (Mettons momentanément de côté la méthode Indiana : le fouet n’EST PAS une solution adaptée à la conduite du changement. Est-ce bien clair ?)
En revanche, il conviendra de s’équiper d’un attirail adéquat en fonction de la situation. Qui sont mes utilisateurs ? Quels sont les canaux de communication les plus adaptés ? Qu’est-ce qui fonctionne bien dans l’entreprise ? Sur quelles ressources puis-je m’appuyer ? sont autant de questions qui aideront à constituer l’équipement de l’aventurier.
Prenons l’exemple d’un kit qui a fonctionné :
des kick-off courts auprès de chaque équipe pour présenter le « pourquoi » du projet, recueillir les besoins et premiers retours et convaincre à l’aide de cas d’usage adaptés en fonction de leurs objectifs ;
des formations sur-mesure et interactives (cet accessoire indispensable est à calibrer en fonction de l’ergonomie et de la facilité d’utilisation de l’outil choisi) ;
du coaching à volonté à l’aide d’un point de contact et de support bien identifié et accessible par les utilisateurs (de ce fait, cela ne peut pas être un directeur, mais quelqu’un qui sera disponible pour les équipes) ;
une documentation abordable, pas trop longue, pour ne pas décourager les élèves, et tenue à jour pour assurer la cohérence du discours ;
des vidéos tutos pas-à-pas, avec une communication régulière, parfois légère ou informelle (via Workplace, SharePoint, mail, voire même papyrus antique).
L’une des composantes principales de la conduite du changement est la communication. L’enjeu sera d’apporter, avec pédagogie, toute la connaissance nécessaire à nos populations concernées, afin de les rendre autonomes et de les convaincre de l’utilité de la démarche. Pour cela, des formations adaptées, couplées à une communication régulière et orientée en fonction du public, seront nécessaires.
La réussite du succès : itérer
Inutile d’arriver avec un schéma de déploiement trop préconçu : avoir des principes, oui, mais rigides, non ! Ce serait le meilleur moyen pour que les utilisateurs n’adhèrent pas. Il nous faudra faire preuve de souplesse et d’agilité pour éviter les écueils et nous emparer des idoles aztèques conservées dans les temples maudits sans se faire transpercer par les flèches piégées.
Plus encore, il faudra également donner la parole à ces parties prenantes de tout horizon et les inclure dans les décisions prises autour du référentiel (nomenclatures, règles de modélisation d’une application, ses instances, ses interfaces, ses composants techniques et les informations complémentaires utiles à renseigner).
Pour faciliter l’acceptation, nous prendrons en compte les points de vue et adapterons l’expédition en fonction des imprévus, qui ne manqueront pas d’arriver (cf. Indy dans « Les Aventuriers de l’arche perdue »), mais qui permettront à coup sûr d’enrichir la portée du référentiel !
Après avoir recueilli les doléances, il sera important de trouver des solutions, de les documenter et de les généraliser auprès de tous les utilisateurs. Les équipes se sentiront plus ainsi engagées et responsabilisées, d’autant plus qu’on aura itéré avec elles sur leurs besoins.
Bien entendu, il faut savoir dire non à certaines demandes, afin de ne pas se retrouver avec une liste au Père Noël qui diluerait les objectifs premiers du référentiel.
Conclusion
Intérieur – une deuxième salle de réunion dans une Université
Responsable d’application
Ça m’a pris du temps, mais j’ai mieux compris à quoi le référentiel allait me servir : partager la carte d’identité de mon application, visualiser ses flux d’échange, anticiper l’évolution de son état de santé technique, pour faciliter les études d’impacts.
Chef de projet
Je peux dorénavant avertir les autres responsables d’application de l’arrivée d’une nouvelle application dans la cartographie et afficher les impacts sur le système d’information. Associé au travail des architectes sur la vision future de l’entreprise, le référentiel prend une vraie valeur.
Directeur d’un domaine applicatif
Je dispose à présent d’une vue exhaustive de mon périmètre et d’informations de qualité sur les applications. Je me porte garant pour assurer la maintenance dans le temps de cette cartographie afin d’en faire bénéficier toutes les parties prenantes de la direction informatique.
Indiana Jones
Is this the real life? Is this just fantasy?
The end
Comme nous le constatons en cette fin de scénario, Indiana a pu lever les réticences majeures à l’aide de sponsors investis, de cas d’usage ciblés et d’une conduite du changement adaptée aux besoins des équipes opérationnelles. L’apport d’un tiers dans la démarche, neutre et indépendant, facilite cette conduite du changement.
Un exemple de la réussite de cette phase de déploiement est d’avoir fait entrer le référentiel d’architecture en tant que « réflexe » dans les mœurs de la direction du système d’information : « As-tu vérifié ce que dit le référentiel à ce sujet ? As-tu capitalisé ton étude SI dans le référentiel ? » Une fois que c’est fait, nous pouvons entrer dans une phase de mise à jour récurrente des informations, à l’aide d’un processus adapté et de KPI pour évaluer la qualité globale du référentiel dans le temps.
De votre côté, comment vous êtes-vous frayés un chemin à travers la végétation luxuriante de l’inventaire applicatif ? Comment avez-vous organisé l’expédition et quel kit du bon aventurier vous a le plus aidé ?
Les données sont partout et nulle part et sont bien souvent intangibles. Notre quotidien devient petit à petit un flot permanent de données générées, collectées et traitées. Elles sont cependant un moyen pour atteindre des objectifs et non une finalité.
Les entreprises doivent donc avoir la capacité à naviguer vers leurs objectifs business, sur une rivière qui deviendra vite un océan de données. L’important maintenant est donc de savoir si elles ont les moyens de braver les éléments.
Les ‘éléments’ auxquels il faut faire face
1. L’obligation de la donnée
La donnée est omniprésente. Données personnelles, confidentielles, de navigation, de consentement, data science, data platform, data visualization, chief data officer font partie d’une longue liste de termes qui font le quotidien des experts mais aussi du client consommateur. Les données sont aujourd’hui un asset reconnu et à forte valeur ajoutée (1). Elles sont aussi un asset pérenne du fait des usages numériques et des opportunités business qui se réinventent tous les jours.
Premier constat donc, l’obligation de la donnée. Elle est un passage obligatoire pour mieux connaître les consommateurs, répondre à leurs nouveaux besoins et être innovant.
2. La surabondance
La digitalisation croissante dans tous les secteurs, les réseaux sociaux, l’IOT, la mobilité, l’utilisation croissante des smartphones sont des exemples qui provoquent une forte augmentation de la génération de données. Les sources se multiplient, les besoins en stockage également (2). Par conséquent, nous sommes vite confrontés à une problématique grandissante : comment maîtriser toutes ces données ? Comment faire face à ce flot surabondant ? Et comment en tirer des informations utiles sans être noyé ?
Les prévisions (3) tablent en effet sur une multiplication par trois ou quatre du volume annuel de données créées tous les cinq ans. Les chiffres sont implacables.
Le deuxième constat est donc la surabondance. Un océan numérique déferle et chaque entreprise, peu importe sa taille, devra y faire face.
3. L’éphémère
Le numérique génère de nouvelles habitudes chez le consommateur : l’instantanéité, le choix abondant et la rapidité de changement. (offre, prix, produit, etc.). Ces habitudes se traduisent par des besoins de plus en plus éphémères. Elles raccourcissent les durées de vie des produits et des services, ou imposent de continuellement se renouveler pour se différencier. Les opportunités marchés sont nombreuses et il faut aller vite pour les saisir le premier. Être le premier est ainsi souvent synonyme de leadership sur le marché. (exemple : Tesla, Airbnb, Uber) L’éphémérité des besoins impose donc d’accélérer en permanence tous les processus internes, métier et SI.
Le troisième constat est donc l’éphémère (besoin, produits, services) qui devient de plus en plus présent. Il est ainsi nécessaire d’être de plus en plus réactif pour s’adapter et évoluer rapidement face à ces changements permanents.
4. L’innovation permanente
Le numérique engendre aussi une accélération de l’innovation. Il rend accessible au plus grand nombre la possibilité de réinventer son quotidien. Cette accélération permanente rend plus rapidement obsolète l’invention d’hier.
Qui aurait en effet pensé que nous allions pouvoir partager nos appartements il y a 10 ans ? Qui aurait pensé que payer sa place de parking se ferait sur son téléphone ? Et surtout qui aurait pensé qu’un téléphone deviendrait l’accès privilégié à toutes nos innovations de demain ?
Le dernier constat est donc l’innovation permanente. Comme pour l’instantanéité, cela génère un besoin de flexibilité et de rapidité fort pour pouvoir suivre le rythme d’innovations imposé par le monde digital.
5. La capillarité de la donnée
Quel est le point commun aux constats précédents ? La donnée. La donnée est présente dans tous les processus et tous les usages en contact ou non avec le client. Ainsi la donnée, par nature, telle la propagation d’un liquide sur une surface, oblige à s’interroger sur les briques du SI qui l’utilisent pendant ces processus et ces usages : c’est la capillarité des données.
Ensuite avec de l’expertise et de la méthodologie, tout s’enchaîne! La définition des besoins et la conception fonctionnelle au travers du prisme “donnée” dans une vision d’ensemble, feront que naturellement par capillarité, vous adresserez le cycle de vie de la donnée, sa valeur et l’architecture de votre SI pour répondre à ces besoins.
Survivre grâce au SI Data Centric
Dans ce contexte de surabondance, d’éphémérité et d’innovation permanente, comment alors maîtriser son patrimoine de données ? Il s’agit de raisonner données et non plus SI. L’objectif devient la gestion de la donnée. Se poser la question de comment gérer des données permet en effet d’adresser ces changements détaillés précédemment et par capillarité, le SI. Un SI centré sur les données est donc le moyen d’adresser ces vagues de changements et de résister aux éléments. En effet, gérer les données impliquent des notions d’unicité, de qualité, de volumétrie, de performance, de confidentialité, d’échanges, de réglementations. L’amélioration de la conception du SI pour faire face à ce nouveau contexte est donc immédiate.
Les fonctions à adresser par le SI, qu’elles soient métiers ou techniques, et la gouvernance nécessaire à la gestion des données vont soulever des questions qui permettront d’adresser ce nouveau contexte d’éphémérité et de surabondance. L’innovation permanente oblige, elle, à industrialiser la livraison des nouvelles fonctionnalités de ce SI centré sur les données. Le SI se construit ainsi autour de la donnée : flexible, modulaire, et industrialisé. Par exemple des référentiels (produits, clients, fournisseurs, etc.) sont mis en place, garantissant la qualité et la mise à jour des données utilisées par toute l’entreprise. Un autre exemple est que les données collectées sont conservées à un seul endroit brutes puis standardisées pour identifier les relations entre elles. Ou encore des outils permettant d’avoir la définition, le cycle de vie et le propriétaire de chaque donnée sont déployés. Le SI devient ainsi un SI centré sur les données. (“Data Centric”).
Il s’adaptera donc naturellement aux futurs changements du marché grâce à tout ce qu’implique la donnée. Il devient un socle solide adressant différents usages sans forcément avoir besoin de transformation en profondeur, longue et coûteuse. Pourquoi ? Car encore une fois, gérer une donnée et faire en sorte qu’elle soit collectée, de qualité, sous contrôle, disponible partout en temps réel et en unitaire ou en masse, intégrées aux processus cœur de métier de l’entreprise, est universel et adaptable à tout usage.
Intrinsèquement la donnée est agnostique de l’usage qu’elle sert. C’est le SI Data Centric qui garantit cette fonction, et assure la survie de l’entreprise dans la jungle digitale.
Conclusion
S’impliquer fortement dans l’évolution du SI est donc nécessaire. L’objectif est de commencer petit mais de commencer Data Centric. Usage après usage, votre SI se construit toujours plus résilient aux différentes vagues de cet océan de données. Un autre bénéfice, et non des moindres : l’innovation des équipes n’étant plus ralentie par le SI, elle s’en trouve ainsi décuplée.
Construire un SI Data Centric, c’est la garantie d’avoir un SI modulaire et adaptable qui répond aux enjeux d’aujourd’hui et de demain. Il est ainsi une base solide sur laquelle construire la pérennité de l’entreprise dans ce nouveau contexte.
Nous aurions pu dresser ici un panorama des technologies, mais mis à part l’intérêt artistique de la présentation, même si l’analyse de notre exemple est très pertinente, sa plus-value en termes d’architecture s’en serait trouvée limitée (1).
Certains proposent une vision basée sur les prérogatives technologiques.
Cette approche (2) oublie la finalité du stockage de la donnée et ne propose qu’un nombre limité de solutions. Nous préférons donc proposer une approche axée sur l’usage de la donnée et sur le besoin utilisateur…
Faisons un rapide tour d’horizon des technologies
Aujourd’hui lorsque nous parlons de data stores, plusieurs familles sont représentées :
Les bases de données relationnelles : Oracle, SQLServeur, MySQL, PostgreSQL, …
D’autres technologies (de stockage ou autres) qui, même si elles permettent de répondre à certains besoins, ne sont pas réellement des bases de données : AWS S3, Azure Blobstorage, Stockage HDFS, Elastic Search, …
Bref, plus de 350 bases de données sont répertoriées à ce jour. Certaines sont uniquement disponibles en PaaS, d’autres sont hybrides et certaines plus traditionnelles ne sont pas éligibles au Cloud(3). Il est donc indispensable de construire une méthodologie qui permette de choisir la technologie qui réponde au besoin.
Pas facile de faire son choix !
Répondre à notre question initiale est bien plus complexe aujourd’hui qu’il y a quelques années, tant les usages ont évolués et les technologies se sont multipliées.
Toutefois pour ne pas se tromper, les bonnes questions à adresser en amont sont les suivantes :
De quelle manière l’application va-t-elle consommer les données : via des appels directs, une couche d’API, des requêtes GraphQL ?
Est-ce que les fonctionnalités attendues doivent être portées uniquement par la base de données ? Ou est-ce que des composants supplémentaires sont nécessaires ?
Est-ce que les transactions doivent être ACID (4) ?
A quelles contraintes du théorème CAP(Consistency, Availability, Partition tolerance) (5) la base de données doit-elle répondre en priorité ?
Quelles structures ou formats de données se prêtent le mieux à l’usage demandé : clé/valeur, colonne, document ou encore graph ?
Quelle va être la volumétrie de ces données ? Quels sont les besoins en termes de performances, de résilience ?
Pour quel type d’usage ? (Décisionnel ? Transactionnel ? Événementiel ?)
Pour quelle nature de données ? (IoT ? Géographiques ? Coordonnées GPS ? Données chronologiques ? Spatio-temporelles ?)
D’autres considérations doivent également être prisent en compte :
Quel sera l’écosystème dans lequel va être hébergée mon application (Cloud ou On Premise) ?
Y a t’il besoin d’accéder aux données lorsque l’application est déconnectée de la base de données ?
Est-ce que je souhaite m’inscrire dans un écosystème intégré (certains éditeurs fournissent des composants qui n’ont plus rien à voir avec le stockage de la données (6)) ?
Quel est le niveau de maturité des équipes de développement, des équipes chargées d’assurer le RUN et l’assistance technique ?
Quel est le niveau de sécurité à appliquer pour protéger les données ?
Au cas par cas, suivant l’usage qui sera fait des données, selon le type des données, selon le niveau de protection nécessaire, nous vous conseillons de construire un arbre de décision cohérent avec l’ensemble des contraintes à appliquer.
Dans certains cas, la solution pour simplifier la spécialisation du stockage sera complétée par une orientation microservice. Cette approche permettra d’exposer et de consommer les données de manière beaucoup plus souple qu’avec l’approche monolithique traditionnelle (un seul data store pour toutes vos données).
Pour en savoir plus sur ces sujets, nous vous invitons à consulter nos articles dédiés :
La solution, concentrez-vous sur le besoin initial
Que l’on se le dise, il n’y aura pas de solution permettant de répondre à l’ensemble des besoins. Les projets qui réussissent sont ceux qui se concentrent sur le besoin initial, prennent en compte le savoir-faire de l’équipe en charge du projet et qui, lorsque le besoin évolue, complètent leur architecture en restant concentrés sur le besoin métier.
En conclusion, la solution de stockage ne doit pas être choisie uniquement en fonction des contraintes technologiques, mais bien en fonction de l’usage qui sera fait de la donnée.
Au sein des DSI, la fonction de Contract Manager a fait ses preuves au cours de ces dernières années.
Suite à la période particulière que nous avons traversé et les conséquences sans précédents observées durant ce printemps 2020, son importance s’est vue décuplée. Ce besoin croissant au sein des DSI peut s’expliquer notamment par certains des questionnements soulevés par Lahcen Elouahi, Senior Manager de Rhapsodies Conseil, lorsqu’il aborde l’impact du télétravail sur les contrats de Soucing IT.
Entre autres :
Comment modifier ses contrats de sourcing pour tenir compte du mode de travail à distance ?
Comment optimiser les coûts de support dans un contexte de travail mixte : sur site et à distance ?
Quels indicateurs de performance, modèle de gouvernance et outillages faut-il mettre en place ?
Comment auditer et faire évoluer ses Contrats IT ?
Partant de la pertinence de ces interrogations, et de la nécessité d’y apporter une réponse adéquate, il est légitime de se demander qui serait le mieux placé au sein de son organisation pour mener à bien les actions attendues ?
Au vu du sujet de cet article, la question est évidemment rhétorique. Cependant, apporter la réponse n’est pas si évident, et de nombreuses entreprises ne parviennent pas à tirer profit du Contract Management. Cette difficulté réside dans la transversalité des sujets concernés, impliquant de fait de nombreux métiers et acteurs de l’entreprise.
Dès lors, il me semble intéressant de comprendre l’origine de la complexité attachée au positionnement du Contract Manager, pour chercher ensuite comment l’intégrer intelligemment au sein d’une organisation.
Comprendre l’origine
Le rôle de la nomenclature des métiers du CIGREF est de rationaliser les métiers de l’IT. La version 2018 de ladite nomenclature a fait ressortir une nouvelle famille de métier, dénommée « Relations Fournisseurs », au sein de laquelle la fonction de Contract Manager (ou « Manager de Contrat » en français) a été déplacée aux côtés de celles de l’Acheteur IT, du Software Asset Manager et du Vendor Manager.
Toutefois, la réalité démontre qu’il est très compliqué de standardiser le rôle et les responsabilités du Contract Manager. Ceci étant dû tant à l’histoire de la fonction, qu’à sa terminologie et/ou à son positionnement. Initialement étranger au secteur informatique, le métier de Contract Manager trouve ses origines dans l’univers du BTP durant les années 1990. Il fait alors partie de ces postes « reflexes » créés en réaction à une action, une inaction ou un besoin inattendu. Dans ce cas précis, le Contract Manager devait répondre à l’émergence de Claims Managers. Ces derniers avaient pour objectifs de maximiser les gains financiers potentiels des contrats dont ils avaient la charge en usant de tous les leviers contractuels disponibles, et ce au détriment de la relation commerciale.
La mission du Contract Manager consista dès lors à s’approprier la gestion du contrat, en privilégiant l’équilibre contractuel et le dialogue nécessaire à une relation commerciale saine. Les Contract Managers sont parvenus à s’approprier le Cycle de Vie Contractuel en liant la théorie juridique, la pratique opérationnelle, l’aspect commercial et les impératifs du contrôleur de gestion.
La combinaison de l’ensemble de ces compétences en fit une fonction transverse. La gestion des risques contractuels fut ainsi simplifiée et entraina une maîtrise efficace et collaborative des cocontractants. Néanmoins, ce métier resté discret en France au cours des années 2000, souffre encore aujourd’hui de sa dénomination anglaise mal perçue par les sociétés et directions françaises. C’est ainsi que l’on retrouve couramment des « Gestionnaires de Contrats » (ou de bases de données contractuelles) dénommés « Contract Manager », chargés de la duplication de documents contractuels, ou de la référenciation massive des contrats. En réalité, leur rôle se rapproche davantage d’un poste de Paralégal ou d’Assistant Administratif. Dans la mesure du possible, cette situation doit être évitée au risque de ne pas rattacher le niveau de compétences adéquat à des missions essentielles.
Au-delà de la terminologie, le Contract Manager souffre également de son positionnement au sein des DSI françaises. Comme cela a été évoqué précédemment, le Contract Manager constitue la pierre angulaire entre quatre métiers essentiels : les juristes (Direction Juridique), les acheteurs (Direction des Achats), les opérationnels (Direction des Opérations) et les contrôleurs de gestion (Direction Financière). Les entreprises fonctionnant majoritairement en silo, la fonction transverse que représente le Contract Manager se voit régulièrement rattachée hiérarchiquement à l’une des quatre directions susmentionnées. Les conséquences ne sont pas anodines, et le profil des Contract Managers se retrouve forcément impacté.
Ainsi, certaines organisations vont faire valoir au Contract Managament une prédominance du métier d’Acheteur, tandis que d’autres organisations pourront décider de recourir majoritairement aux compétences juridiques, et d’autres encore préférer y rattacher les missions d’un Service Delivery Manager.
L’intégration d’une cellule de contract management
Lors de la construction d’une cellule de Contract Management au sein de votre DSI, c’est une réalité qu’il est impératif de prendre en compte. Il est pertinent de se demander en autre :
Quels sont les objectifs recherchés ?
Quelles sont les performances supplémentaires attendues ?
Quelle typologie de risques m’affecte le plus ?
Quels outils et processus peuvent-être adaptés, modifiés, optimisés ?
La réponse à ces questions stratégiques permet la création d’un RACI pertinent et adéquat dont il ressort généralement une typologie de « profil de Contract Manager ». Cette information est clef dans la construction, le rattachement et donc le positionnement du Contract Management. Chaque situation étant spécifique, il n’y a pas de mauvaise solution. En revanche, une cellule de Contract Management correctement positionnée, bénéficiant d’un maximum de rôles et responsabilités transverses, permettra non seulement d’éviter de nombreux travers et points de blocages, mais aussi d’assurer une gestion des risques et des fournisseurs performants.
Les autres articles qui peuvent vous intéresser
25 juin 2025
Pilotage & Performance Opérationnelle et Contractuelle
Dans le contexte actuel, quelle organisation n’a pas pour objectif “d’être plus agile” ? Être plus agile, la clé du succès ? Oui, mais comment y parvenir ?
Agile … is an attitude, not a technique with boundaries. An attitude has no boundaries, so we wouldn’t ask “can I use agile here”, but rather “how would I act in the agile way here?” or “how agile can we be, here? »
Alistair Cockburn
En traduction synthétique « L’Agilité, c’est un état d’esprit pas seulement des pratiques ! ». D’expérience, nous savons qu’appliquer un framework agile ou utiliser des outils estampillés agiles (JIRA, Trello…) ne sont aucunement une garantie que vous allez évoluer vers un état d’esprit agile. La notion d’état d’esprit renvoie à la complexité humaine, une complexité qui se caractérise par un grand nombre d’éléments en relation d’interdépendance et sans coordination centrale. Pas facile de s’y retrouver… sauf si nous utilisons la pyramide de Dilts. C’est un modèle que je trouve très pertinent pour structurer ces éléments et mettre en évidence leur relation.
Mais avant d’utiliser ce très beau modèle (mini teasing, il va falloir patienter encore un peu), revenons-en à notre objectif, à cet état d’esprit agile que l’on vise. (car nous savons que « Tout objectif flou conduit irrémédiablement à une connerie précise. » Anonyme)
Pour clarifier notre objectif, commençons par le sens des mots :
1. Qu’est ce qu’un état d’esprit ?
C’est un état mental qui agit comme un filtre dans nos désirs et nos interprétations, nous prédisposant ainsi à penser, à parler et à agir d’une certaine manière.
Exemple : Avant le démarrage d’une compétition, le sportif se plonge souvent dans un état d’esprit de grande certitude. Les imprévus pendant la compétition généreront ainsi moins de doutes en lui, trop de doutes pouvant impacter négativement sa motivation ou lui faire perdre sa concentration.
Au contraire, entre chaque entraînement, le sportif pourrait adopter un état d’esprit de curiosité et de remise en question. Le doute sera dans ce cas-là une ressource positive pour le sportif, lui permettant d’envisager de meilleures solutions pour améliorer son entraînement.
Cet exemple souligne combien il est important d’adapter son état d’esprit en fonction de la situation et des objectifs que l’on poursuit. Si vous n’en êtes pas encore intimement persuadés, je vous suggère de regarder le TedX Change your mindset, change the game | Dr. Alia Crum.
Une seconde question nous vient alors tout naturellement
2. Qu’est-ce qu’un état d’esprit agile ?
Si nous associons l’Agilité au manifeste du développement agile de logiciels, nous pouvons dire que dans ce cas-là, l’état d’esprit agile recherché serait d’être prédisposé à penser, à parler et à agir en cohérence avec les 4 valeurs et 12 principes de ce manifeste.
On peut bien entendu étendre notre définition aux 5 valeurs et aux 3 piliers de Scrum (si l’on utilise ce framework)
ou au triptyque : build the right thing, build the thing right, build it fast
ou à quelque autre concept que l’on associe à de l’agilité. Il n’y a pas une seule bonne réponse de ce qu’est un état d’esprit agile.
La bonne question à se poser pour trouver la définition de l’état d’esprit agile que vous recherchez est :
3. Pourquoi développer cet état d’esprit agile ?
Effectivement, avant la question du « comment », posons-nous la question du « pourquoi » (<- j’ai Simon Sinek qui me le chuchote constamment à l’oreille depuis que j’ai vu son TedX Simon Sinek – Comment les grands leaders inspirent l’action )
Globalement, nous pouvons voir l’agilité comme une réponse au contexte VICA : Volatile, Incertain, Complexe, et Ambigu (VUCA en anglais), qui devient de plus en plus une norme dans le monde de l’entreprise.
Si nous voulons développer un état d’esprit agile, c’est parce nous voulons nous doter de la capacité de penser et d’agir de façon adaptée et performante dans ce contexte.
Prenons un exemple en utilisant comme guide de réflexion l’une des 4 valeurs du manifeste du développement agile de logiciels : “les individus et leurs interactions plus que les processus et les outils”. Si vous êtes dans un contexte changeant, alors les processus et les outils qui ont tendance à figer le système, sont une barrière à votre adaptation. Vous devez alors porter votre attention aux individus et aux interactions qui leur permettent de s’adapter au contexte. Dans ce cas, un état d’esprit agile est primordial.
Maintenant, si vous êtes dans un environnement avec une faible variabilité (pas VICA), il y a de fortes chances de gagner plus rapidement en performance en travaillant sur l’axe des processus et des outils plutôt qu’en travaillant sur l’axe des individus et interactions. Ce serait là un état d’esprit moins agile mais qui serait pertinent vis à vis du contexte.
A travers cet exemple quelque peu provocateur pour l’agiliste convaincu que je suis, je veux montrer qu’il vous faut adopter un état d’esprit plus ou moins agile selon le contexte. Tout comme pour notre sportif, un état d’esprit de grande certitude est bénéfique en phase de compétition mais est néfaste en phase d’entraînement.
Après avoir mûri notre réflexion sur l’état d’esprit que l’on recherche (un état d’esprit adapté à notre contexte), nous pouvons passer à :
4. Comment favoriser l’émergence de l’état d’esprit recherché ?
C’est le moment d’introduire la pyramide de Dilts. Ce modèle se compose de 6 niveaux qui se superposent avec une gradation des aspects les plus concrets en bas aux aspects les plus abstraits en haut.
Note : le « nous » dans les questions peut faire référence aussi bien à un individu qu’à une équipe ou une organisation (<- une pyramide multi usages, cool, non ?). Chaque niveau a une influence sur tous les autres mais il reste plus étroitement lié au niveau qui est juste en dessous et juste au-dessus de lui.
Pour mieux saisir les relations entre les niveaux successifs, prenons un exemple : Imaginons une équipe qui passe de la responsabilité de maintenir un produit en fin de vie à celle de développer un nouveau produit. Nous sommes dans le cas d’un changement au plus haut niveau de la pyramide, au niveau du sens (mission).
L’équipe va naturellement se poser la question de ce qu’elle doit modifier dans son mode de fonctionnement pour s’adapter à cette nouvelle mission.
Nous allons répondre à cet enjeu en utilisant la structure du modèle de Dilts par un questionnement à chaque niveau :
Etape 1 – niveau sens :
Quel est le changement au niveau du sens (mission) ? Quelle est votre nouvelle contribution à quels nouveaux clients / utilisateurs ? (pour notre exemple, l’équipe a une nouvelle mission qui est de développer un nouveau produit pour des utilisateurs X)
Etape 2 – au niveau identité :
Quels sont les aspects de votre rôle que vous aviez qui ne sont plus en phase avec votre nouvelle mission ?
Quel est le nouveau rôle que vous devez jouer pour apporter des résultats plus en phase avec votre nouvelle mission ?
Etape 3 – A partir du nouveau rôle qui a été identifié, nous procédons aux mêmes questions avec le niveau inférieur, le niveau des valeurs et croyances :
Quelles sont les valeurs et les croyances que vous aviez adoptées qui ne sont plus en phase avec ce nouveau rôle ?
Quelles sont les valeurs et les croyances que vous devez adopter pour être plus performant dans ce nouveau rôle ?
Et nous descendons ainsi de suite sur tous les niveaux jusqu’au niveau le plus bas qui est l’environnement.
Ce déroulé de questions par niveaux successifs va faire ressentir à l’équipe la nécessité d’un alignement, d’une cohérence, d’une « relation + / + » entre tous les niveaux pour obtenir la contribution la plus efficace au niveau de sa nouvelle mission.
Si nous n’avions pas utilisé ce questionnement structuré sur les niveaux de la pyramide, il est probable que l’équipe ait répondu sur des modifications à faire au niveau des capacités, des comportements et de l’environnement (par ex : passage de Kanban à Scrum et colocalisation avec l’équipe métier) mais pas au niveau des valeurs et croyances et de l’identité. On peut imaginer que l’équipe devra délaisser un état d’esprit orienté efficience et process (qu’elle avait adopté pour maintenir un produit en fin de vie) pour aller vers plus de souplesse et de priorité aux interactions dans le développement du produit avec l’équipe métier.
Une autre clé de compréhension de la pyramide de Dilts est que l’influence entre les niveaux est plus importante dans le sens descendant que dans le sens montant. De fait, il est souvent préférable de régler un problème qui se situe à un niveau par un changement au niveau supérieur. Par exemple, si vous observez que le Product Owner transforme les daily meeting en séance de reporting (problème au niveau des comportements), l’exclure du daily meeting (solution au niveau des comportements) va sûrement transférer le problème ailleurs (il viendra solliciter l’équipe pour du reporting à d’autres moments que le daily). La solution est peut-être à trouver sur les niveaux supérieurs, comme au niveau des capacités en renforçant le management visuel ou au niveau de l’identité (un product owner n’est pas la traduction de chef de projet en anglais !).
Je vous propose un dernier exemple qui montre l’importance de la cohérence entre les 6 niveaux logiques.
Avant ma bascule dans le domaine de l’Agilité, je travaillais dans une entreprise où les départements collaboraient peu efficacement entre eux. Une année, le PDG se décide à prioriser dans les objectifs l’amélioration de la collaboration entre départements (notamment évolution du rôle et des responsabilités et donc du niveau identité) au service d’une plus grande performance collective (niveau sens). Il fait une annonce à ce sujet et une formation est dispensée au plus grand nombre afin d’accompagner ce changement. C’est une formation qui met en avant des principes comme « nous sommes tous des clients internes », « les optimums locaux ne font pas un optimum global »,etc. Le but était de changer le niveau des croyances et des valeurs afin qu’elles soient plus en phase avec le changement désiré au niveau identité (collaboration) et au niveau sens (performance collective). Cette formation n’a aucun effet durable car les autres niveaux (environnement, comportements, capacités) ne sont pas alignés et propices à cette plus grande collaboration. Tous les collaborateurs de l’entreprise ont des objectifs individuels. Chaque département a ses propres objectifs qui peuvent être quasiment en conflit avec ceux des autres. Chaque équipe déjeune séparément des autres. Les éléments que je viens de citer ont une rétroaction beaucoup plus forte que l’action de la formation, le système revient à l’équilibre. Ce fut une belle démonstration des interactions fortes entre les niveaux de la pyramide de Dilts et du principe d’homéostasie.
Conclusion
En synthèse, voici l’articulation des réponses que je vous propose à notre problématique initiale “Comment être vraiment agile avec la pyramide de Dilts ?”
L’agilité n’est pas une finalité en soi. Analyser d’abord votre contexte (notamment sur son aspect VICA) et les objectifs poursuivis par votre organisation afin d’identifier quel est le niveau d’agilité le plus pertinent à mettre en place
On peut être vraiment agile à condition que notre état d’esprit soit agile. Préciser donc les caractéristiques de l’état d’esprit qu’il vous faut adopter (notamment en fonction du niveau d’agilité défini précédemment).
Analyser chacun des niveaux de la pyramide de Dilts afin de définir les incohérences et manques qui empêchent l’atteinte de cet état d’esprit et qui freinent votre performance dans votre mission (niveau du “sens”, niveau le plus haut de la pyramide)
Définissez les actions qui pourraient être entreprises pour commencer à faire évoluer chacun des niveaux dans la direction souhaitée et les prioriser
Mettez en oeuvre ses actions et vérifier leur efficacité dans la poursuite de ce nouvel état d’esprit
Observez les changements d’état d’esprit opérés et assurez vous qu’ils ont un impact positif sur vos performances
Bravo ! Félicitez-vous ! Vous avez accompli un beau chemin. Vous pouvez maintenant itérer en revenant à l’étape 4) ou challenger le tout et revenir à l’étape 1)
C’est un bravo sincère sur cette étape 7) car l’utilisation de la pyramide de Dilts nécessite de l’humilité et une vraie volonté de remise en cause (qui aime révéler ses incohérences ?) pour être pleinement performante. Ce travail sur les blocages et les incohérences entre les 6 niveaux du modèle va fluidifier et aligner l’état d’esprit et l’action sur la mission. C’est un chemin qui va libérer tous les potentiels de votre organisation !
