Vous avez des APIs pour interconnecter les systèmes ? Parfait c’est une belle première étape. Asseyons-nous maintenant pour parler de résilience et de découplage… Une nouvelle étape s’ouvre : les APIs Asynchrones ? Mais quelle obscure clarté, quelle douce violence est-ce donc que cela ??
Un petit récap, pourquoi parler d’APIs asynchrones ?
Le sujet des APIs asynchrones résonne depuis quelques années dans la tête des architectes, et ces derniers en font de plus en plus un de leurs objectifs : une API, donc un contrat d’interface bien défini, qui s’affranchit des défauts des APIs. Comme disait le sage Bruno dans son article : “Favoriser l’asynchronisme est un bon principe de conception de flux”.
Ce besoin d’éviter un couplage fort et de créer des SAS de décompression entre les différentes applications / parcours est certainement cohérent, mais est à priori en contradiction avec la nature même des API et du protocole HTTP. Alors comment concilier le meilleur de ces deux mondes ?
Commençons par les bases, une API asynchrone, concrètement, c’est quoi ?
Une API asynchrone est une API recevant, par exemple, la commande d’un client, client qui n’attend pas la réponse de celle-ci dans l’immédiat. Le seul retour mis à disposition par l’API, dans un premier temps, est la prise en compte de la demande (un « acknowledgement » : vous avez bien votre ticket, merci d’attendre).
Le fournisseur d’API effectue les actions nécessaires pour satisfaire la requête, sans forcément être contraint par des timeouts, en gros il peut prendre son temps pour en garantir la bonne exécution.
Et dans la pratique ?
En pratique, cette architecture peut être garantie par le couple API qui poste dans une queue / topic assurés par un outil de type MOM.
L’API déverse les informations dans une queue (ou topic) du MOM, informations qui sont ensuite prises en compte suivant les disponibilités des applications en aval. L’application appelée devient un consommateur d’un flux asynchrone, ce qui permet de découpler les deux.
Pour notifier, ça passe crème
Ce type de comportement est facilement mis en place lorsque nous nous trouvons dans des cas de figure non critiques, dans lesquels par exemple on doit notifier un utilisateur LinkedIn de l’anniversaire d’un de ses contacts : en tant que client, tant pis si l’information n’arrive pas, nous pouvons accepter un manque de fiabilité.
Un peu moins quand l’objectif porte sur un échange critique
Tout change quand le demandeur s’attend à quelque-chose, soit une information soit une confirmation forte de la livraison de l’information , car cet aspect demeure crucial pour son bon fonctionnement. Dans une API synchrone, nous l’obtenons à la fin de la transaction.
Dans le cas asynchrone, comment garantir le même comportement lorsque la transaction se termine ?
C’est à ce niveau que les avantages de l’asynchronisme induisent une complication de gestion, complication dont souvent les équipes n’ont pas conscience. Une confirmation de réception (“acknowledgement”) est dans ces cas insuffisante (ex. votre transaction bancaire s’est bien passée, comme par exemple un virement).
Mais alors comment notifier le client du résultat ?
La mise en place d’une logique de réponse peut être construite de deux façons différentes.
En mode PULL
Le mode pull présuppose que l’action soit toujours à l’initiative du client.
L’API met à disposition le statut de l’action (sous forme de numéro de suivi), sans notifier le client. C’est au client de venir vérifier le statut de sa demande, en faisant des requêtes de suivi à des intervalles réguliers.
En mode PUSH
Le mode push suppose que le canal de communication soit ouvert dans les deux sens, et que le serveur ne soit pas forcément tenu d’attendre une requête du client pour “pousser” l’information.
Certaines technologies et patterns d’architecture, permettent de mettre en place ce mode de communication, pour citer les plus connus :
Le protocole websocket permettant l’ouverture de canaux pour établir une communication bidirectionnelle entre serveur et client,
Les mécanismes de CallBack et Webhooks,
Les constructions réalisées avec des MOMs, basées sur des queues / topics d’aller et d’autres de retour, qui se traduisent en patterns request / reply implémentés par certains de ces outils,
Basés sur des solutions similaires au précédent point, des patterns d’architecture custom permettant de gérer ces aller-retours entre applications.
Les patterns schématisés ci-dessous ne sont pas exhaustifs mais ont pour objectif de montrer des exemples réels de contraintes, en termes de flux, apportées par les trois modes : synchrone, asynchrone pull et asynchrone push.
Synchrone
Asynchrone Pull
Asynchrone Push
Mais alors, push ou pull ?
L’utilisation d’un pattern par rapport à l’autre doit être réfléchie, car donner un avis tranché sur la meilleure solution est assez compliqué sans connaître l’environnement et les contraintes. Les deux techniques sont fondamentalement faisables mais le choix dépendra du besoin réel, des patterns supportés par les socles déjà déployés et des applications difficilement intégrables en synchrone.
Notre avis est d’éviter au maximum les solutions pull, car ces méthodes impliquent des aller-retour inutiles entre les applications.
Comment mettre du liant entre aller et retour ?
La mise en place d’une API asynchrone présuppose donc une certaine attention à l’intégrité fonctionnelle entre la requête et la réponse, qui ne sont pas, dans le cas de l’asynchronisme, forcément liées par la même transaction.
Pour garantir l’intégrité fonctionnelle et le lien entre la requête et la réponse, surtout dans le cas d’une notification PUSH, un échange d’informations pour identifier et coupler les deux étapes est nécessaire. L’utilisation d’informations spécifiques dans l’entête des requêtes, comme dans le cas d’APIs synchrones, est une solution performante, tout en s’assurant d’avoir mis en place les bonnes pratiques de sécurité visant à éviter l’intrusion de tiers dans la communication. Sans vouloir réinventer la roue, les mécanismes déjà en place pour d’autres technologies peuvent être repris, comme par exemple les identifiants de corrélation, chers au MOMs, identifiants qui permettent de créer un lien entre les différentes communications.
Si on utilise des mécanismes non natifs aux API, pourquoi passer par une API et pas par un autre moyen asynchrone ?
Le choix de passer par une API a plusieurs raisons, suivant le cas d’usage :
c’est le standard actuel auquel la plupart des solutions ont adhéré, avec un fonctionnement API first même si le besoin est asynchrone
l’éventuelle gestion par API gateway, rendue possible sur une construction asynchrone par cette solution, demeure très pratique pour la gestion des échanges, avec des avantages que les protocoles / solutions asynchrones classiques ne sont pas prêts d’intégrer
Cela ne limite pas pour autant le spectre d’APIs asynchrones au seul HTTP. Bien que le standard OpenAPI soit fortement focalisé HTTP, d’autres standards ont été conçus expressément pour les cas d’usage asynchrone.
Exemple, la spécification AsyncAPI. Cette spécification se veut agnostique du protocole de communication avec le serveur, qui peut être du HTTP, mais également du AMQP, MQTT, Kafka, STOMP, etc. standards normalement employés par des MOMs.
Conclusion
En conclusion, notre conviction est que l’asynchronisme est vraiment la pièce manquante aux approches API. L’APIsation a été un formidable bond en termes de standardisation des interfaces mais reste jusque là coincée dans son carcan synchrone. L’heure de la pleine maturité a sonnée !
Les autres articles qui peuvent vous intéresser
Pourquoi partir des utilisateurs et non plus des besoins
Pourquoi partir des utilisateurs et non plus des besoins
Nous le constatons encore aujourd’hui, certains projets n’aboutissent jamais, ou alors après des mois voire des années de mise en œuvre et sont boudés par les utilisateurs.
Malgré une gestion des changements, la plateforme n’est jamais utilisée et l’application meurt (on l’espère rapidement) sans jamais rencontrer ses utilisateurs.
Dans certains cas, le projet “stratégique” a été validé par la Direction, la technologie en haut à droite du cadran du Gartner a bien été déployée, mais au final les cas d’usage sont beaucoup trop compliqués à intégrer sur la plateforme. Ces projets finissent souvent en échec, les ressources ont été gaspillées et l’image de la DSI en pâtit.
Enfin, dans d’autres cas, l’étude s’éternise pour concevoir, et planifier l’architecture qui répondra à l’ensemble des cas d’usages et qui permettra de résorber la dette technologique. Ces cas de figure trop fréquents partent malheureusement de bonnes intentions. Il s’agissait de couvrir l’ensemble des besoins existants et d’absorber les besoins qui ne manqueront pas d’arriver à court et moyen terme.
Une approche frugale
La meilleure solution consiste à se concentrer sur quelques utilisateurs clés pour prendre en compte des fonctionnalités précises qui peuvent être implémentés sous forme de MVP en quelques sprints et le faire évoluer pour prendre en compte les nouveaux besoins.
L’architecture de la solution devra rester souple et prévoir “by design” de pouvoir intégrer de nouveaux composants et technologies qui répondront demain à des nouveaux besoins.
Pour réussir cette mise en œuvre, il faut donc réunir une équipe pluridisciplinaire qui sera en charge de :
Collecter et analyser les besoins des utilisateurs
Définir l’architecture fonctionnelle et de données
Définir l’architecture technique
Constituer et suivre la backlog
Concevoir et mettre en œuvre les développements
Déployer l’architecture technique
Au démarrage du projet il faudra donc :
un Product Owner
un architecte en charge des aspects fonctionnel, applicatifs et data
un architecte technique
un scrum master
un ou plusieurs développeurs spécialisés sur les stacks à mettre en oeuvre
un cloud-ops
Un Business Analyste
Une organisation efficiente
Cette organisation s’inspire des Pizza Teams (l’ensemble des membres d’une équipe doit pouvoir se nourrir sur une Pizza Américaine). Elle vise à simplifier la communication au sein d’une équipe. En effet, le nombre de liens entre les personnes d’une équipe peut être calculé avec la formule suivante (1) :
( N x (N -1 ) )/ 2
Où N est égale au nombre de personnes dans l’équipe.
Plus le nombre de personnes est important plus les échanges sont importants et les risques et le temps consacrés aux échanges sont importants.
La mobilisation de l’équipe permettra de produire au fil des sprints des versions de plus en plus abouties, revues régulièrement par les utilisateurs.
En quelques semaines, une première version pourra être déployée en production sur le périmètre jugé prioritaire par les utilisateurs.
L’adoption ne sera plus un problème, car les utilisateurs auront participé à la conception de leur outil et remonteront directement les fonctionnalités prioritaires.
Au fil des évolutions, l’équipe pourra être élargie pour prendre en compte des besoins impliquant des nouvelles briques d’architecture et de nouvelles technologies. Il faudra toutefois rester vigilant afin de ne pas dépasser le nombre critique de membres dans l’équipe.
Une dynamique dès le cadrage
Un cadrage initial est indispensable avant de lancer le projet. Certes l’organisation projet et le user-centrisme sont des facilitateurs, mais la clef dans le succès de la démarche se trouve en amont. Si au lieu de demander aux utilisateurs quels sont leurs besoins et de les hiérarchiser par priorités, nous leur demandions leurs envies ?
Les utilisateurs vont être concentrés sur ce qui est vraiment important dans leur travail et ce qui va leur simplifier la vie. Si l’application a de multiples utilisateurs, il faudra les amener à trouver un consensus et à présenter une liste commune. Cette liste sera la base de la backlog projet et devra être affinée afin de la rendre implémentable.
Faire adhérer les décideurs
Cette approche projet nécessite de rassurer les décideurs. En cela la méthode agile est insuffisante. Le burn out chart ou les autres indicateurs sont utiles au pilotage agile des projets, mais suffisent rarement à rassurer les décideurs sur les aspects coûts / délais / valeur ajoutée des projets.
Il faut donc trouver des indicateurs complémentaires, aptes à rendre compte de l’avancement des sprints, mais qui permettent aussi d’apporter de la visibilité aux décideurs qui n’ont que faire des points de complexités et autres idiomes agiles.
Revoir la méthode
La réussite des projets passe par une remise en question profonde de nos méthodes d’architecture. Le framework TOGAF nous donne de bonnes bases, mais elles sont loin d’être suffisantes pour aller vers de l’architecture SI agile.
Les évolutions de l’architecture découlant des besoins métiers et non plus d’une planification détaillée réalisée en début de projet et implémentée dans un cycle de plusieurs mois ou années, cela nous amène à adresser des problématiques qui remettent en cause nos méthodes de travail :
Les projets font de plus en plus souvent appel à de l’expérimentation. Les composants sont testés sur des calendriers resserrés et suivant l’adéquation par rapport au besoin, sont adoptés ou abandonnés.
Les schémas d’architecture initiaux sont vite obsolètes et ne seront maintenus qu’en contrepartie d’un investissement conséquent à faible valeur ajoutée pour l’utilisateur.
Les technologies évoluent (trop) vite, la maîtrise des technologies par les équipes de support et d’exploitation prend beaucoup plus de temps.
Les utilisateurs ne comprennent plus que l’informatique professionnelle soit décorrélées des technologies mises à dispositions par les GAFA.
Les projets sur plusieurs années sont obsolètes avant d’être ouverts aux utilisateurs.
Pourtant des méthodes et outils inspirés du design thinking, du Lean ou du manifeste agile sont là pour nous aider avec par exemple :
La méthode sprint pour l’expérimentation ;
Des outils de documentation automatique des architectures qui garantissent des schémas toujours à jour (2) ;
Une organisation devops et une automatisation du traitement des incidents ;
Une approche itérative des projets, pour apporter de la valeur aux utilisateurs de manière linéaire sans sacrifier la qualité.
Certains argumentent que ces transformations sont réalisables à l’échelle des startups ou de compagnies digital natives, mais c’est oublier que le dev-ops tire son origine du monde industriel, certes beaucoup moins souple que l’IT, mais où la transformation vers le lean a été une condition de survie. The phoenix project (3) illustre très bien les parallèles entre le monde industriel et l’agilité , plus proche de notre quotidien, la gestion des maintenances des TGV est opérée par la SNCF via des tableaux agiles où l’ensemble des bonnes pratiques sont respectées.
Se transformer pour survivre
Les architectes n’auront bientôt plus le choix, les projets planifiés à plusieurs années induisent trop de risques :
tant sur le budget (il est de plus en plus difficile d’obtenir un budget pluriannuel pour un projet qui délivrera dans un futur éloigné)
que sur l’adoption utilisateur : la solution prévue ne correspondra plus aux priorités du business lorsqu’elle aboutira.
L’architecte doit donc à la fois porter une vision à long terme permettant de respecter les règles de l’entreprise, garantissant l’exploitabilité de l’application et être capable de faire opérer des changements d’architecture pour répondre aux priorités métier à court terme.
Un changement de paradigme est nécessaire pour passer d’une organisation ou les technologies sont des capacités de soutien qui fournissent des services, des plates-formes ou des outils spécifiques au reste de l’organisation, tels que définis par les priorités, les ressources et le budget, à une organisation ou les technologies sont parfaitement intégrées et au cœur de tous les aspects de l’organisation en tant que moyen de libérer de la valeur et de permettre des réactions rapides aux besoins des entreprises et des parties prenantes (4).
Il nous faut nous habituer à la distribution de valeur dès le début du projet et nous préparer à prendre en compte les nouveaux besoins à chaque nouveaux sprints.
Les utilisateurs doivent se sentir impliqués, considérés. Leurs remarques doivent être valorisées afin de rentrer dans un cercle vertueux qui permettra de délivrer de l’expérience utilisateur de qualité en continu.
Le succès des projets dépend maintenant de la capacité des architectes à prendre en compte les besoins des utilisateurs, afin de toujours pouvoir s’adapter aux priorités métier et délivrer de la valeur au plus près des enjeux business. Ces changements bousculent certainement les habitudes ancrées dans la DSI, mais la valeur dispensée aux utilisateurs justifiera l’investissement à apporter dans ces changements.
La question est légitime, car le CRM doit contenir l’ensemble des Clients / Prospects et l’information peut être tenue à jour par les commerciaux qui les rencontrent régulièrement. Mais avant de faire ce choix, quelques interrogations méritent d’être levées.
La gouvernance à mettre en place est-elle compatible avec mon CRM ?
Le CRM n’est pas le seul système à pouvoir créer, compléter ou mettre à jour des données Clients. Les systèmes de gestion, de facturation ou autres frontaux Clients influent également sur la vie de ces données. Appliquer au CRM l’étiquette de référentiel n’est donc pas suffisant. Il faut mettre en place l’ensemble de la gouvernance des données de référence Client (ou plus généralement concernant les Tiers) associées au principe de référentiel :
Définir le cycle de vie des Clients,
Définir un modèle objet exhaustif (qui ne soit pas limité aux seuls besoins du service commercial),
Pour chaque attribut, définir quels utilisateurs seront en capacité de le mettre à jour, à partir de quel outil, le tout en fonction du statut ou de l’état du Client,
Mettre en place une couche pour assurer la qualité de la donnée (formatage, dédoublonnage, contrôle de cohérence, complétion via des bases externes, …),
Prévoir les mécanismes et processus de validation des données,
Construire les interfaces nécessaires afin de consolider et de diffuser la donnée,
Définir les droits/politiques d’accès à la donnée,
Anticiper les impacts sur le pilotage, le reporting, la traçabilité, le versionning des données, la gestion des données à date, …
Quel modèle de donnée client dans le référentiel ?
Il faut également garder en mémoire que les CRM se concentrent par nature sur les éléments ayant trait à la relation commerciale avec les Clients. Or l’ensemble des données du CRM ne sont pas forcément à porter dans un référentiel. Inversement, dans bien des cas un CRM ne contient pas l’ensemble des données référentielles d’un Client (rôles du Client [payeur / commanditaire / bénéficiaire…], données techniques liées à la mise en place d’un service pour le Client…).
Construire le référentiel Client au sein du CRM implique donc de s’assurer que ce dernier contienne bien l’ensemble des données référentielles et de pouvoir aisément distinguer celles-ci des données à caractère opérationnel.
De plus, dans de nombreux cas cela implique également que des acteurs non commerciaux aient accès au CRM afin de maintenir ces données Client. La Direction Commerciale et Marketing souhaitera-t-elle ouvrir son outil à ces acteurs ? Ceux-ci accepteront-ils d’utiliser le CRM, outil qui n’est pas fait pour répondre à leurs propres besoins ?
Quel périmètre de données est concerné ?
Lorsque les clients sont des personnes morales, il peut être intéressant de croiser les données afin de savoir quels sont les clients qui sont également fournisseurs, quel est le chiffre d’affaire généré par un Client/Fournisseur vs la charge que représente ses prestations. Toute consolidation risque d’être complexe si les référentiels Client et Fournisseur sont distincts. Il s’agit pourtant dans les deux cas de personnes morales mais gérer ses Fournisseurs dans un CRM ne fait pas forcement sens. Dans ce cas, un référentiel ad hoc permettrait de pallier le problème. La problématique sera identique pour tout autre tiers d’intérêt comme les apporteurs d’affaire, les sous-traitants, les cautions / garants…).
Et la technique dans tout ça ?
Point inhérent aux précédents, le CRM a-t-il les capacités techniques pour assurer le rôle de référentiel ? Est-il capable de faire de la gestion de la qualité des données ? Ou alors s’intégrer avec un outil de DQM (Data Quality Management) spécifique ? Est-ce que le modèle de données du CRM est compatible ou suffisamment personnalisable afin d’intégrer le modèle de données de l’entreprise ? L’outil aura-t-il les capacités techniques pour diffuser l’information au sein du SI ? Supportera-t-il des dizaines de milliers de requête par jour ? Est-ce que le contrat de service associé à ce CRM est suffisant pour permettre à l’ensemble des applications qui en dépendent de fonctionner correctement ?
Est-ce que je fais un bon investissement ?
Les aspects financiers sont également un élément-clé de la décision. Certes, de prime abord, utiliser le CRM comme référentiel Client permet d’éviter un investissement dans un nouveau système, mais à quel prix ? Combien coûte la mise en place (et l’exploitation) des fonctionnalités de référentiel au sein d’un CRM ? Combien coûtent la haute disponibilité, la qualité de service, les SLA qui n’étaient peut-être pas nécessaires pour le simple usage des commerciaux ? Combien coûtent les licences supplémentaires attribuées aux utilisateurs qui n’étaient pas dans le périmètre initial ? Le modèle de facturation du fournisseur est-il en cohérence avec l’usage que l’on souhaite en faire (un coût à l’usage peut s’avérer rapidement très onéreux) ? Est-ce que l’économie est réelle lorsque l’on compare cette option à la mise en place d’un référentiel dédié ?
Quelles sont les autres solutions possibles ?
Si le CRM n’est pas l’outil le plus adapté à votre cas, quelles sont les autres possibilités ?
Les MDM (Master Data Management) sont a priori plus aptes à traiter les problématiques de référentiel de données puisqu’ils ont été développés dans cette optique. Ils possèdent des fonctionnalités pour traiter la saisie, la consolidation et la diffusion des données et intègrent généralement une couche de DQM permettant d’en assurer la qualité.
Toutefois, la prudence s’impose car tous les outils n’ont pas forcement la même maturité et tous proposent des fonctionnalités qui répondent à des besoins qui ne sont peut-être pas les vôtres. Pourquoi payer les fonctionnalités d’un progiciel si c’est pour ne pas les utiliser ?
Pour répondre à des besoins relativement simples, le développement d’une solution spécifique pourrait être considéré.
Quelle est la meilleure solution pour mon référentiel client ?
CRM, MDM ou développement spécifique, il n’y a pas de réponse générique, mais il peut y avoir des conséquences sur l’ensemble du système d’information.
Bien que tous les éditeurs (de CRM) soutiennent que leur solution peut être utilisée en tant que référentiel Client, ils sont beaucoup plus tempérés une fois les besoins et contraintes à traiter exprimés.
Par ailleurs, et non des moindres, il faut noter que ce n’est pas uniquement le réceptacle qui fait le référentiel. C’est bien la gouvernance qui encadre la donnée qui permet de maintenir le point de vérité. Il est nécessaire de mettre en place une organisation avec des rôles et responsabilités définis ainsi que des outils adaptés respectant l’urbanisation et l’architecture du système d’information.
Mais n’en sommes nous pas à la vision 360° client désormais ?
Encore une fois, malgré des éditeurs de CRM et de MDM qui promettent la Vision 360° Client, il faut replacer ces solutions à leurs « justes » fonctionnalités et regarder vers de nouveaux outils autour du Big Data qui permettent effectivement la mise en place d’une « vraie » Vision 360° Client sans pour autant remplacer le CRM ni le Référentiel Client. Ces visions consolidées et cross-business sont généralement utiles aux clients eux-mêmes mais aussi et surtout aux commerciaux ou gestionnaires pour leur permettre d’être encore plus efficient dans leur travail au quotidien.
Notons surtout que ces nouveaux outils ne font que renforcer l’intérêt d’un Référentiel Client qui soit partagé au sein du SI car construire une vision 360° Client nécessite d’agréger en un point unique des données venant de l’ensemble du SI.
De nouveaux types d’architecture, incluant la mise en place de Data Lake, d’API, de frontaux digitaux permettent la construction et l’utilisation de cette vision 360° mais elle ne restera possible que si les données peuvent être corrélées les unes avec les autres. Cette corrélation est grandement facilitée lorsqu’un référentiel Client a été mis en place au cœur du système d’information. La vision 360° n’a alors plus qu’à relier tous les éléments métier autour du « golden record » Client unique.
Les autres articles qui peuvent vous intéresser
Le Cloud, un tremplin vers la Transformation Digitale ?
Le Cloud, un tremplin vers la Transformation Digitale ?
Le marché français était en léger retard depuis quelques années sur l’adoption du Cloud. Les entreprises américaines étant les premières à avoir fait le saut dans l’informatique en nuage. Pourtant les derniers chiffres issus du baromètre Markess indiquent une très forte hausse d’adoption depuis 2 ans avec une évolution annuelle tournant autour des 25-30%.
Nous avons pu confirmer ce changement lors de notre dernière visite au Salon Cloud Computing World Expo qui s’est tenu Porte de Versailles à Paris.
La première raison de ce changement est que pour certains domaines professionnels, les nouveaux standards du marché sont parfois uniquement disponibles à la demande (i.e. Office365 ou G-Suite). De nombreuses entreprises ont fait le choix de migrer leur messagerie et outils bureautiques devenus obsolètes vers des outils de collaboration plus adaptés au monde digital. A ce sujet, les collaborateurs en entreprise sont de plus en plus demandeurs de retrouver le même confort qu’ils ont à la maison : avoir accès à leurs applications depuis internet via différents devices (PC, tablette, portable).
Autre exemple, les solutions CRM étaient auparavant dominées par des socles logiciels très lourds à déployer et à maintenir. Beaucoup de sociétés veulent gagner en agilité et souhaitent limiter leurs investissements (CAPEX) en migrant vers des solutions Saas (i. e SalesForce.com). Ceci leur permet de déployer rapidement aux métiers des solutions tout à fait adéquates sans avoir besoin de développer des fonctions spécifiques sur mesure.
Comme l’a exprimé Emmanuel Guichet, directeur de la division IT Factory du groupe Total, lors d’une conférence:
« réaliser un projet de 18-24 mois pour concevoir les 20% de fonctionnalités manquantes n’est plus acceptable par la Direction Générale pour ce type d’application ».
Autre effet, inattendu il y a quelques années, le Cloud est vu maintenant comme un levier de croissance. Avec l’arrivée de nouveaux concurrents issus du monde du web, certaines entreprises ont été forcé à prendre des initiatives en dehors de leur business model habituel. Ceci a souvent nécessité la mise en place de nouvelles plateformes pour faire du Big Data ou s’interfacer avec des objets connectés (IoT) pour certains cas d’usages. Or ces innovations se font souvent en mode incrémental voir expérimental et ne justifient pas toujours les lourds investissements nécessaires au démarrage de ces projets. Il peut être pragmatique, comme l’a fait LeBonCoin.fr, d’externaliser ces briques applicatives afin d’adopter un paiement à l’usage pour mitiger ce risque.
Cette même stratégie permet de concevoir et de construire son architecture en mode Agile à moindre frais d’infrastructure sans avoir peur de tout remettre en cause. En fonction de la taille de votre structure, de vos compétences en interne et de la criticité de vos données, il vous restera ensuite de choisir les briques technologiques et le fournisseur Cloud appropriés.
Ces nouveaux entrants « disruptifs » ont également une particularité commune : ils ont tous des cycles de développements très courts ! Ils peuvent délivrer des nouvelles fonctionnalités en peu de temps à leurs utilisateurs finaux. Les entreprises traditionnelles se voient forcées d’abandonner leurs méthodes de gestion de projet classiques basées sur des cycles en V.
Elles doivent adopter des méthodes Agiles, Lean voire de revoir en profondeur leur organisation pour adopter une culture DevOps. AXA et la Société Générale, ont toutes les deux déclaré publiquement avoir entamé ces transformations importantes dans le but ultime de réduire leur « Time to Market ».
Les deux sociétés ont été contraintes pour des raisons réglementaires de s’appuyer dans un premier temps sur un Cloud Privé mais ont donné des indications de vouloir aussi s’appuyer sur du Cloud Public dans la mesure du possible. La Société Générale a indiqué avoir fait le choix d’utiliser des containers Docker pour faciliter la migration d’un Cloud à un autre et ainsi avoir un véritable Cloud hybride.
S’appuyer sur le Cloud a un effet bénéfique sur le budget opérationnel (OPEX) de ces entreprises. Cela leur a permis de rationaliser leur nombre de datacenters comme indiqué par la société minière et métallurgique Eramet.
Elles profitent de ces migrations pour revoir leur portfolio applicatif et décommissionner celles avec peu de valeur ajoutée comme le rapporte Thierry Favier, responsable informatique chez eSNCF.
Enfin, toutes celles venues témoigner au Salon ont entrepris de piloter la migration de leur SI Legacy vers le Cloud en tenant compte de deux critères majeurs : la réduction de coût et les risques opérationnels.
Le résultat est que pour toutes ces entreprises, s’appuyer sur du Cloud dans leur transformation digitale a été une évidence. Elles ont toutes défini en amont une stratégie de déploiement (Saas, PaaS, IaaS) propre à certains cas d’usages ou besoins fonctionnels. Que ce soit pour couvrir de nouveaux besoins, venir en appui de changement d’organisation et de culture ou pour réduire leur coût tout en se modernisant, elles n’ont pas hésité à franchir le pas !
Le Cloud est donc bien un tremplin vers la transformation digitale.
Le métier de consultant est une véritable aventure ! Chaque mission, chaque client est une occasion de découverte mais aussi une opportunité d’inventer, d’expérimenter, d’utiliser et de développer ses talents. Cette fois-ci parlons de la médiation, c’est-à-dire l’art de résorber ou d’atténuer les conflits.
Les enjeux humains chez os clients mettent parfois en danger nos missions
Consultants, nous constatons toujours dans nos interventions, aussi techniques soient-elles, qu’il y a des enjeux humains qui impactent les problématiques que nous avons à traiter. Être rigoureux, s’en tenir aux faits, développer des convictions, communiquer largement, expliquer nos démarches de réflexions, gérer nos interlocuteurs, etc. nous avons des actes-réflexes pour faire face.
Mais souvent c’est pire ! Les situations relationnelles de nos clients ressemblent à des conflits. Et ce n’est pas étonnant, car des conflits il y en a dans toutes les sociétés ! Pour éviter que nos interventions en subissent directement le poids, nous mettons alors en place des dispositifs palliatifs supplémentaires comme :
Des hypothèses de production et des KPI (pour se protéger des défaillances du client) ;
Des stratégies de travail (pour pouvoir avancer malgré tout) ;
Des stratégies de validation (pour obtenir des quitus).
La résolution des conflits produit de la valeur
Mais dans certains cas, on a tout intérêt à faire un peu plus, ou un peu différemment. En effet, si les stratégies précédentes (actes réflexes et dispositifs palliatifs) permettent de s’en sortir honorablement, elles ne sont pas complètement convaincantes : le conflit rencontré demeure non résolu. Moralité : on a fait le job mais pas plus.
Si on pouvait résoudre le conflit en question, on pourrait prouver notre engagement à notre client et ainsi l’aider à obtenir des résultats inespérés.
La médiation est faites au profit des parties
D’un naturel « communiquant et sensible », j’ai découvert l’art de la médiation pas à pas. Je vais vous exposer mon approche du sujet. Précisons que la médiation se rapproche de la négociation, mais une grande différence les sépare : la négociation est conduite dans l’espoir d’un gain personnel, alors que la médiation est conduite au profit des parties, pas du médiateur.
La démarche de médiation est toujours implicite (seuls ses résultats sont explicites)
Première bonne pratique : le consultant n’étant pas mandaté pour conduire une médiation, devra en constater le besoin et la conduire sans le dire. Si les parties prenantes du conflit avaient conscience d’une telle démarche, elles pourraient modifier leurs comportements au point de la faire échouer. Cela vaut aussi pour le consultant : il doit faire l’effort de ne pas paraître avoir de parti-pris (et il pourrait en avoir compte-tenu des enjeux de la réussite de la médiation sur sa mission). En ce sens la mission initiale et explicite du consultant (conduire un projet, définir une architecture, produire un rapport d’analyse, etc.) est un paravent très commode !
Deuxième bonne pratique : être curieux. Il faut observer, écouter et discuter pour diagnostiquer la situation relationnelle conflictuelle. Le projet technique que l’on conduit étant toujours le cœur de la discussion -jamais ladite médiation- : pourquoi ce projet ? quelles difficultés pressenties ? conditions de réussites ? vécu des parties prenantes ? leurs craintes ? leurs opinions ? etc.
Troisième bonne pratique : faire émerger au sein du projet technique, un sous-projet (ou sujet latéral) sur la base duquel on fera progressivement collaborer les interlocuteurs en conflit. 4 étapes pour cela :
Détourer pour soi-même le périmètre sur lequel les 2 parties peuvent converger (« chacune des 2 parties seraient satisfaites si … »).
Présenter à chacune des 2 parties le périmètre en question et s’assurer qu’elles se l’approprient et sont suffisamment en confiance (« compte-tenu de ce qui vient de vous être présenté et de tout le reste, comment voyez-vous la mise en œuvre ? »).
Proposer une collaboration encadrée, soutenue par le consultant, qui doit déboucher sur un premier résultat encourageant (et la découverte mutuelle qu’il est possible de collaborer, même si cela reste non formulé : on ne pointe du doigt que le résultat obtenu, pas les personnes, car leur implication reste fragile à ce stade).
Solliciter un retour d’expérience, pour ancrer l’idée qu’une démarche commune est possible (« que pensez-vous de la démarche qu’on vient d’accomplir ? », « quelle pourrait être une suite naturelle possible ? »)
Trois illustrations de médiations réussies
Voici 3 contextes différents, où sur la base de notre mandat préalable de consultant et du diagnostic d’un conflit, notre envie d’aller plus loin nous a conduit à produire plus de valeur que les analyses et livrables qui nous étaient initialement demandés.
En 2011, nous assistons le pilotage d’un grand projet de refonte du SI et tout est bloqué. Sous le poids des incertitudes les chefs de chantiers sont mode « défense passive » et se renvoient tous la balle : « les livrables en entrée de mon activité sont incomplets, je ne peux pas travailler ! ».
Sujet latéral et périmètre de convergence. Sous couvert de mettre à plat la méthode projet pour des besoins de gouvernance, nous concevons avec l’ensemble des acteurs la map du déroulement du projet sur 1 an ½ tel que chacun le voit, que nous publions et affichons dans tous les couloirs.
Collaboration encadrée et convergence. Nous organisons tous les jeudis un point d’avancement rassemblant les chefs de chantiers concernés par l’étape en question : le chef de projet s’y fait expliquer la situation, détoure une solution acceptable pour les chefs de chantiers et leur apporte son soutien (moyens, prise en charge des risques, etc.).
En 2014, dans une société de transport, nous intervenons pour revoir l’ensemble des processus opérationnels pour les besoins réglementaires (conformité sécurité). Cela est nécessaire à la bonne marche de l’entreprise, mais le responsable des processus s’est construit une tour d’ivoire et sa chef, à défaut de pouvoir le piloter, envisage de déléguer cette activité à un autre service. Leurs cultures, technique d’un côté et administratif de l’autre, les opposent.
Périmètre de convergence. Sous couvert de redéfinir le livret des processus, 1) nous détaillons les services rendus, la valeur ajoutée de l’activité et le planning des prochaines étapes, 2) nous faisons exprimer à la chef de service les KPI pour piloter l’activité. Nous rapprochons services, valeur ajoutée et planning des KPI attendus.
Sujet latéral, Collaboration encadrée et Convergence. Nous définissons un tableau de bord commun aux 2 parties qui leur permet de communiquer. Nous soutenons les 2 parties lors des premières itérations de tableaux de bord. Les 2 parties au bout de quelques semaines se font part de leur satisfaction.
En 2017, nous devons diagnostiquer l’organisation d’un des Services d’une filiale bancaire et définir un plan de modernisation de l’organisation. Le tout nouveau Directeur ambitieux se confronte au chef de service et à son équipe de « vieux briscards » présents dans la société depuis 25 ans pour certains :
« Je ne sais pas ce qu’ils font », « quand je m’adresse à eux, c’est comme si je parlais à des tombes »
« il ne cherche pas à nous connaître, il ne connaît même pas nos noms », « il ne sait pas toute la valeur qu’on produit »
Comment mettre en mouvement un tel équipage ?!
Périmètre de convergence. Passé le diagnostic initial, nous définissons un plan d’action de changement acceptable pour le Directeur et le Chef de Service.
Sujet latéral.Nous définissons avec le Directeur 10 sujets sur lesquels il voudrait voir des progrès. Nous partageons ces sujets avec les équipes et lançons 10 groupes de travail, où nous n’intervenons qu’en support (planification des ateliers, aide méthodologique). L’objectif est de démontrer la valeur des collaborateurs par leur capacité à traiter les sujets en autonomie.
Collaboration encadrée. Sur la base de l’accord trouvé sur le plan d’action, nous demandons au Directeur et au Chef de Service de soutenir unanimement et de manière univoque les groupes de travail : pour chacun des 10 sujets en cours de traitement, ils définissent l’aide qu’ils pourront l’un et l’autre apporter aux collaborateurs.
Convergence. La revue finale a lieu :
les 10 groupes de travail présentent tour à tour leurs résultats. 8 ont vraiment réussi l’exercice et les 2 autres sont plus en retrait. 2 groupes brillent (celui sur le management du Service notamment !)
le Directeur constate la valeur de ses équipes et leur apporte son soutien, ainsi que le Chef de Service.
le Directeur et le Chef de Service sont « alignés » pour la première fois depuis des mois
Quand la médiation échoue
Il arrive que la médiation échoue : à tout moment une partie ou des deux peuvent sortir du jeu en refusant de collaborer. C’est souvent le fait d’un écart culturel trop prononcé, de divergences trop ancrées, d’une envie d’en découdre ou d’une rupture qui est déjà trop engagée, etc.
Cette approche de la médiation appliquée aux missions de conseil, demande du temps, de l’écoute, de la patience et surtout l’envie d’aider ses congénères. Cependant, par rapport à un médiateur professionnel, le consultant-médiateur avance masqué : on l’a vu faire, on a accepté son approche (on voit bien ce qu’il fait) … on voit la situation s’améliorer, mais son rôle de médiateur n’est pas formellement reconnu. Il pourrait y avoir un risque à vouloir être reconnu comme médiateur : devoir reconnaître formellement qu’il y a un conflit … rare qu’on ait envie d’officialiser les difficultés qu’on ne sait pas résoudre. Comme dans le voyage de Monsieur Perrichon, les témoins de nos faiblesses, sauveteurs patentés soient-ils, deviendraient rapidement gênants et auraient tôt fait d’être délaissés !
L’architecture, tout comme les technologies, évolue constamment. Un architecte doit donc s’adapter et suivre une formation continue pour rester à la pointe de son domaine.
Pour fournir une vision d’ensemble du SI et de sa transformation, l’architecte doit faire émerger les principes du « vivre ensemble » partagés par l’ensemble des parties prenantes du SI.
Un SI construit sans vue d’ensemble c’est ça
Et les connexions entre applications ressemblent à ça
Construire ensemble
La cible du SI et ses paliers de transformations fournis par l’architecte d’entreprise sert à donner à chacun la vision d’ensemble dans laquelle il s’insère.
Lorsqu’une solution n’est pas compatible avec la direction donnée et les bases de la construction, elle peut avoir de grandes répercussions sur les autres, voire mettre l’ensemble de la construction en danger (ici la structure de l’immeuble a failli s’effondrer sous le poids supplémentaire).
Chacun a son point de vue sur la solution, et tout le monde a raison (de son point de vue évidemment)
Chacun imagine des solutions, même si celles-ci peuvent paraître en décalage avec l’idée qu’on s’en fait. Des dérogations peuvent être accordées tant qu’elle ne gêne pas l’ensemble de la construction l’architecte d’entreprise ou le difficile équilibre du vivre ensemble L’architecte d’entreprise ou le difficile équilibre du vivre ensemble discussion
Une fois que la cible est définie et partagée par tous, il faut alors effectivement définit les règles du vivre ensemble
L’architecte d’entreprise est là pour proposer des principes communs qui permettent de faire avancer le SI dans son ensemble. Il a pour but de faire communiquer les différentes composantes de l’entreprise et de trouver les solutions qui conviennent à tous, qui sont les plus pérennes et les plus proches des standards voulus par l’entreprise. Dans notre monde actuel, les connaissances sont fragmentées et la coopération entre toutes les parties est essentielle pour tirer le meilleur des nouvelles situations et des technologies.
L’architecture globale du SI doit permettre de laisser chacun libre d’aménager (ou pas !) son propre espace (l’intérieur de sa solution). Le but est alors que chaque solution puisse vivre selon son propre rythme en harmonie avec les autres et en garantissant un langage minimum commun pour se comprendre.
Peu importe la solution choisie pour le SI, la bonne solution est celle qui répond au problème. Elle doit être partagée par tous, construite suivant les règles de l’art et chacun doit pouvoir y trouver sa place.
Quelques grandes règles et principes suffisent pour construire ensemble un édifice solide. À tout moment, il doit être possible de justifier des principes qui nous ont amené à choisir cette solution. Ces principes peuvent (doivent) évoluer bien sûr. Ils sont là pour nous aider à se poser les (bonnes) questions. La gestion des dérogations à ces mêmes principes est un art subtil à manier avec précaution et à ne pas négliger !
La bonne architecture fournit la solution adaptée à un besoin en prenant en compte les différents paramètres de coûts, délais, qualité, esthétique, technique, évolutivité etc.
