Participez à notre événement Sobriété Numérique avec Axa et la STIME
Suite aux travaux que nous avons menés dans notre livre blanc “Continuum de la sobriété numérique”, nous vous invitons à une table ronde exceptionnelle pour parler sobriété avec des intervenants engagés sur ces sujets. Ces derniers seront invités à partager et à débattre autour de ces questions essentielles :
Quel est le rôle de la sensibilisation et de la formation?
Comment mettre le “marketing” et ses techniques au service de la sobriété ?
Peut-on vraiment réussir sa transformation “Numérique Durable et Responsable” sans imposer des vraies contraintes (sur les volumes de données, les consommations, quotas…) ?
Comment sortir de l’impasse d’un système numérique en accélération permanente (5G, 6G, NG, GenAI, Metaverse, ….) ?
Et à l’inverse, comment percevoir les signes positifs apparents en ce moment (Montée en puissance des fresques du numérique, CSRD, …).
Sont-ils suffisants pour marquer le début d’une bascule ?
Quelles actions concrètes dans les organisations pour accélérer la sobriété du système d’information ?
Rhapsodies Conseil vous invite le mardi 24 septembre à 8h30 à un événement éco-conçu, engagé et responsable au centvingtseptbypixelis avec le traiteur meetmymama.
Notre table ronde sera animée par Rémy Marrone, Journaliste Indépendant en Marketing et Numérique Responsable, en présence d’invités exceptionnels :
Alexandra Bouet-Rochard, Responsable ESG – IT & Opérations Services au sein de Crédit Agricole – CIB
Céline Lescop, Lead Digital Sustainability & Data Architect au sein de AXA Group et Membre du groupe de travail à The Shift Project
Emmanuelle Bravard‑Sarraz, Directrice Communication et RSE à la STIME – DSI Les Mousquetaires
Gilles Juan, auteur indépendant de livres et documentaires, consultant en ingénierie pédagogique,
Mathieu Bourgeois Avocat associé – Immatériel & Numérique chez Klein & Wenner et Membre fondateur du Cercle de la Donnée
Jean-Baptiste Piccirillo, Senior Manager en charge de l’expertise Numérique Durable au sein de Rhapsodies Conseil, auteur de “Continuum de la sobriété”
Olivier Marchand, Team Leader Numérique Durable chez Rhapsodies Conseil
Rythmée, cette table ronde sera l’occasion pour nos intervenants de vous faire part de leurs retours d’expériences, de partager leur vision et leurs questionnements, et enfin d’aborder les actions concrètes qu’ils ont mis en place dans leurs organisations autour de ces enjeux.
A cette occasion, nous vous remettrons un exemplaire du livre-blanc « Continuum de la sobriété numérique ». Merci de confirmer votre participation pour que nous puissions assurer votre place !
Consultante senior Transformation Agile des Organisations
L’agilisation de Geopost, ou comment transformer l’urgence en opportunité avec l’aide de Rhapsodies Conseil
Le cas client de Geopost, le leader européen de la livraison de colis, offre une illustration de la dynamique de résolution des défis complexes, des changements profonds et des bénéfices significatifs qui accompagnent les transformations de grande ampleur.
Chez Geopost une première transformation agile a été menée en 2019 dans le département IT avec comme résultat la mise en place de pratiques agiles dans quelques équipes. En partenariat avec Rhapsodies Conseil, cabinet indépendant de conseil en management spécialisé dans l’accélération des projets de transformation, Geopost a entrepris une évolution vers plus d’agilité dans le cadre du programme « FastTrack » qui vise à améliorer le tracking de colis.
C’est une question cruciale pour Geopost, puisque le tracking de colis est au cœur des attentes du clients, que la concurrence propose des solutions plus performantes et que le développement à l’international les oblige à rationaliser pour optimiser les coûts avec un décommissionnement de l’ancien outil prévu en octobre 2022.
Cette initiative est l’occasion d’étudier l’opportunité d’une nouvelle organisation centrée sur équipes pluridisciplinaires qui collaborent sur un produit ou une fonctionnalité (nous parlons de Product Teams ou Feature Teams).
Durant les 12 mois d’accompagnement par Rhapsodies Conseil, nous avons adressé la transformation avec une approche produit : alignement sur des valeurs, principes et pratiques agiles, découpage des sujets, priorisation par la valeur et cadencement avec des saisons de transformation (comme des sprints).
Les trois phases de la transformation
Vision et préparation du backlog de transformation
Pour permettre une bonne appropriation et une pérennisation de la démarche, il est nécessaire de démarrer par une présentation de la démarche auprès des sponsors impliqués. Nous avons conduit les sponsors à affiner leur vision et leur démarche, unissant leurs forces pour garantir une approche cohérente et efficace. A la suite de cette étape, les sponsors ont partagé cette vision avec l’ensemble des collaborateurs impliqués pour donner du sens, faciliter l’adoption et la mise en mouvement.
Il a été aussi indispensable de réaliser une analyse approfondie de l’existant en collaboration avec les parties prenantes concernées. Cette étape permet de dresser un état des lieux précis des pratiques, des processus et des structures en place, ainsi que d’identifier les forces et les faiblesses du système actuel. Les modalités de cette analyse incluent diverses techniques telles que l’observation des tableaux de bord et des instances existantes, des entretiens avec les acteurs clés, ainsi que la tenue d’ateliers collaboratifs tels que le radar de maturité agile. Ces actions permettent de recueillir des informations pertinentes et de favoriser l’engagement et la participation active de toutes les parties prenantes.Suite à cette analyse, nous constatons des dysfonctionnements et des problématiques « classiques » propres aux programmes à fort enjeux évoluant dans des environnements complexes et distribués sur plusieurs pays. Cette étape révèle également la présence de résistances et de croyances limitantes concernant l’agilité, qui peuvent entraver le processus de transformation. Cependant, il est important de souligner que cette phase ne se limite pas à l’identification des obstacles, mais qu’elle met également en lumière les leviers et les forces disponibles. Parmi celles-ci, on peut notamment citer des pratiques agiles déjà en place, l’envie des collaborateurs de faire mieux ainsi que leur engagement dans le programme. Ces éléments positifs constituent des points d’appui essentiels pour la suite de la démarche.
Pour conclure cette phase, nous avons restitué le backlog de transformation co-construit pour aligner les équipes sur le point de départ, la vision cible et les priorités. A l’issue de cette démonstration, les parties prenantes se sentent concernées et ont envie d’expérimenter : nous avons obtenu là une première mobilisation proactive.
Saison de transformation de deux fois un mois
La réussite d’une transformation agile repose sur des modalités de réalisations précises et adaptées aux besoins spécifiques de l’organisation. Pour cela, plusieurs étapes et actions ont été nécessaires afin de garantir une transition fluide et efficace vers un mode de fonctionnement agile.
Un premier aspect essentiel consiste à travailler avec des groupes de travail sur les sujets priorisés du backlog. Cette approche, par “petits pas”, permet de cibler rapidement les actions à haut impact et de générer des résultats tangibles à court terme (“quick wins)”. En concentrant les efforts sur les problématiques les plus pressantes, on favorise une progression mesurable dans la transformation.
Parallèlement, des workshops ont été organisés pour favoriser l’évolution des comportements, des interactions et des pratiques au sein de l’organisation. Ces sessions visent à acculturer l’ensemble des collaborateurs à l’agilité, en leur fournissant un langage et un mindset communs. Un séminaire de co-construction de la nouvelle organisation en Features Teams a été notamment organisé, suivi d’un accompagnement pour sa mise en place effective. D’autres workshops sont dédiés à des aspects spécifiques de l’agilité, tels que la priorisation par la valeur des Epics et des User Stories, la définition des attentes et des responsabilités des différents rôles, ainsi que la mise en place des cérémonies agiles et de la comitologie ad hoc au niveau des équipes et de manière transversale.
Un exemple concret illustre l’impact positif des workshops qui ont été menés lors de cette phase : la prise de conscience des difficultés de la roadmap initiale, qui présentait de nombreuses contraintes. Grâce à une analyse approfondie et à des discussions collaboratives, les participants ont pu identifier les points d’amélioration et proposer des solutions adaptées, par exemple : Construire une macro roadmap à 6-12 mois en 1 slide; identifier les jalons clés; réduire le nombre de sujets en cours de 50%.
En outre, la systématisation des rétrospectives contribue également à faire évoluer les pratiques et les relations au sein de l’équipe. En favorisant un climat de confiance et de transparence, ces réunions d’évaluation et d’apprentissage continu permettent de renforcer l’engagement des membres de l’équipe et d’identifier les axes d’amélioration pour les prochaines itérations.
Stabilisation
Dans cette dernière phase d’une durée de 6 mois, l’objectif principal était de renforcer un nouvel équilibre au sein de l’organisation en adoptant de nouveaux modes de fonctionnement vertueux. Cependant, comme il est courant (et humain), les équipes ont eu tendance par moments à revenir inconsciemment à leurs anciennes habitudes pour retrouver l’ancien équilibre. Pour contrer cela, il est essentiel de maintenir le cap sur le sens et la vision définis précédemment, tout en continuant à expérimenter et à ancrer des pratiques qui apportent une réelle valeur ajoutée, par exemple : réalisations des actions d’amélioration continue identifiées lors de rétrospectives (création d’un wiki, travaille en binôme, ajustement de responsabilités, aligner les dates de fin de sprint avec les dates de livraison…).
Cet ajustement s’est traduit par la mise en œuvre d’ateliers et d’un suivi ad-hoc pour renforcer les nouvelles pratiques. Cela inclut la rédaction des User Stories, le traitement des bugs, la rédaction des Definition of Done (DOD) et Definition of Ready (DOR), ainsi que d’autres aspects clés du processus agile. Ces activités permettent de maintenir un niveau élevé de qualité et d’efficacité dans la réalisation des tâches et des livrables.
De plus, la mise en place de tableaux de conception Kanban et l’évolution vers un mode de fonctionnement Scrumban offrent une meilleure visibilité et un meilleur contrôle sur les flux de travail, ce qui facilite la gestion et la coordination des activités au sein des équipes. En parallèle, un accompagnement spécifique est fourni à la communauté de chapters pour optimiser le delivery. Cette démarche vise à renforcer la collaboration et l’échange de bonnes pratiques entre les différentes équipes et à favoriser une culture de l’amélioration continue.
Nous avons initié une culture de la mesure dans le but d’améliorer la performance et la qualité du delivery. Partant d’une équipe pilote, nous avons créé de nouveaux tableaux de bord qui présentent les indicateurs clés sur les dimensions : flux de travail, prédictibilité, qualité. En nous appuyant sur des données factuelles, l’équipe a pu prendre des décisions éclairées pour optimiser ses processus.
Un autre aspect crucial de cette phase d’ajustement concerne la révision et l’optimisation de la roadmap du projet. Il s’agit d’un besoin clé pour garantir une direction claire et un alignement optimal au niveau du programme et des équipes. Auparavant, la gestion des priorités était source de confusion et d’inefficacité, avec des pratiques telles que la priorisation biaisée par les priorités individuelles. Cela entraînait un nombre excessif de sujets en cours, une planification chaotique et une absence de priorisation par la valeur.
Grâce à un mentorat hebdomadaire du Product Owner sur une période de quatre mois, les équipes ont pu parvenir à un alignement et à un affinage significatifs de la priorisation de la roadmap, en utilisant la méthode ICE (Impact, Confidence, Effort). Ce processus a nécessité du temps et des efforts, mais il a permis aux équipes d’apprendre à dire non de façon la plus objective possible, de réduire le nombre de sujets en cours et de mettre en pratique le principe selon lequel « choisir, c’est avancer”, conformément à la philosophie agile.
Moments forts et bénéfices
La décision d’expérimenter l’évolution agile avec ce programme prioritaire et urgent représentait un pari risqué, mais elle a finalement été couronnée de succès, offrant une série de bénéfices significatifs à l’organisation.
L’atteinte de la deadline du jalon d’octobre 2022 a été une étape cruciale, offrant une meilleure prédictibilité dans les livraisons, une visibilité accrue sur l’avancement des projets et une réduction significative du time to market. Ce succès a renforcé le sentiment d’engagement chez les collaborateurs, qui ont vu leurs efforts et leur implication récompensés par des résultats tangibles. La confiance en l’équipe et en la direction s’est consolidée, créant ainsi un environnement propice à l’innovation et à la collaboration.
L’évolution agile a dynamiquement adapté les pratiques au sein du programme et du département, engendrant un effet papillon organisationnel. Les équipes ont adopté un mindset agile, favorisant la flexibilité, la collaboration et l’adaptabilité. Cette évolution a renforcé la culture d’innovation, positionnant l’organisation vers la croissance et le succès à long terme. Un bénéfice majeur est l’émergence d’une culture d’amélioration continue, avec la mise en place de KPI’s agiles (prédictibilité, delivery workflow, qualité). Les équipes ont intégré les principes agiles, devenant autonomes et garantissant une adaptabilité et une innovation soutenues, assurant ainsi la compétitivité de l’entreprise.En outre, les bénéfices concrets ont été observés lors de la célébration marquant cette étape importante juste avant le gros jalon du décommissionnement. La démonstration de la transformation agile par les parties prenantes du programme (équipes “Fast Track”, sponsors et Rhapsodies Conseil) à l’ensemble des équipes IT & Process. La “foire agile » (événement de partage et expérimentation des pratiques agiles) a renforcé la vision commune, le lien entre les équipes, l’engagement des collaborateurs et suscité un intérêt croissant pour l’adoption de pratiques agiles au sein du reste de l’organisation. A l’issue de cet événement, deux équipes extérieures au périmètre initial ont lancé leur transformation agile et une communauté de pratiques agiles a émergé, ce qui atteste de l’ancrage durable de cette transformation dans la culture de l’entreprise.
“Au démarrage, nous étions 2 à être intéressés par l’agilité et ses leviers d’évolution organisationnelle. Après deux années d’accompagnement, tout le monde en parle, du DSI jusqu’aux fonctions transverses. Nous sommes très contents et ne manqueront pas de vous re-solliciter”.
Vers une livraison continue : les stratégies et bonnes pratiques pour concevoir une usine logicielle CI/CD performante
Vers une livraison continue : les stratégies et bonnes pratiques pour concevoir une usine logicielle CI/CD performante
La mise en place d’une usine logicielle CI/CD (intégration et déploiement continu) est un élément clé pour les équipes DevOps. Cependant, il existe un débat sur la meilleure approche pour atteindre cet objectif : construire en interne ou acheter une solution sur le marché.
Dans les 2 cas, un investissement initial est nécessaire, mais indispensable pour obtenir des résultats probants sur la durée.
Toutefois, les options sont nombreuses et variées. Dès lors, toutes les possibilités offertes sur le marché peuvent rapidement dépasser une entreprise.
La transition vers le DevOps implique un changement culturel et une collaboration étroite entre développeurs (Dev) et exploitants (Ops). Cette évolution repose sur le choix judicieux et la mise en œuvre efficace d’une chaîne d’outils adaptée.
Quels sont les éléments à prendre en considération pour construire un écosystème DevOps à la fois agile et performant ?
Quelles sont les étapes pour mener à bien cette réflexion ?
L’usine logicielle : l’outil indispensable pour une approche DevOps réussie
Une usine logicielle (UL) permet d’automatiser les processus liés au développement de logiciels avec une approche structurée. L’usine logicielle tire son inspiration des pratiques de Toyota dans les années 70, avec des processus de fabrication automatisée.
Les objectifs auxquels répond ce type de plateforme sont multiples :
Réduire les pertes de temps et gagner en efficacité
Maintenir une qualité du code tout au long de la chaîne de production
Livrer des fonctionnalités à forte valeur ajoutée
Détecter les régressions applicatives immédiatement grâce aux tests et obtenir rapidement le feedback utilisateur sur les risques commerciaux
Améliorer et développer le logiciel de façon continue
Les développeurs réduisent les risques lors des déploiements en utilisant une plateforme commune pour le contrôle de version, l’analyse de code, et les tests.
L’orchestration et l’automatisation de ces activités fiabilisent ainsi les mises en Production. Elles assurent une livraison continue du produit tout en restant conforme à l’évolution du marché.
Il est désormais incontestable que les entreprises qui adoptent la culture DevOps bénéficient d’un retour sur investissement significatif. Pour plus d’informations, consultez notre article les 6 bonnes raisons afin de vous convaincre de franchir le pas !
Travailler avec une architecture de référence
Pour commencer, utilisez une architecture de référence pour guider la construction d’un système de développement et de livraison automatisé.
Une plateforme DevOps est constituée d’outils nécessaires à l’industrialisation du développement. Ces outils peuvent être regroupés sous 5 grandes familles d’activités :
Réaliser : Ensemble des capacités nécessaires à la construction, l’assemblage et aux tests du code en continu
Livrer : Ensemble des capacités visant à déployer les applications et leurs infrastructures en continu
Orchestrer : Ensemble des capacités de coordination et de l’automatisation de tâches
Superviser et Exploiter : Ensemble des capacités à surveiller et à assurer la disponibilité de la Production
Planifier et Collaborer : Ensemble des capacités de simplification du partage et de communication entre les équipes de réalisation
Chaque famille comprend plusieurs fonctions qui ne sont pas destinées à être toutes implémentées, et encore moins au même moment. Ainsi, vous pouvez réaliser les tests de non-régression en dehors du pipeline et les intégrer dans un deuxième temps.
La création d’une usine logicielle nécessite une vision à court, moyen et long terme. Elle nécessite l’application des bonnes pratiques dès le début, et une réflexion sur le niveau d’intégration souhaité.
Définir sa stratégie de déploiement et d’organisation UL
Combien de chaînes DevOps à mettre en place ? Pour quels besoins ?
La définition de l’architecture de référence n’est que la première étape de votre démarche.
Avant de commencer à construire des pipelines de livraison de logiciels, il est crucial de définir les utilisateurs de ces usines.
L’usage doit être étudié sous plusieurs aspects :
par technologie : l’UL est construite en fonction du langage de programmation : python, java, framework .NET… Elle sera utilisée par les équipes et applications qui développent suivant ces technologies
par criticité de l’application : l’UL regroupe une ou plusieurs applications en fonction de sa criticité au sein de l’entreprise
par département : l’UL est considérée au niveau du département/direction. Les applications d’une même branche d’activité sont intégrées au sein de cette UL. Toutefois, il est possible de rationaliser les applications de plusieurs départements au sein d’une seule UL.
par type de plateforme et d’infrastructure : l’UL est utilisée par les applications se trouvant uniquement sur une infrastructure On-premise. Une autre UL est créée pour les applications hébergées dans le Cloud
Mettre en place plusieurs pipelines n’implique pas une totale autonomie de chaque équipe en matière de choix technologiques et de stratégie globale.
Avant de créer une UL, il est essentiel que les équipes coopèrent, partagent leurs décisions et alignent leurs savoir-faire pour le déploiement et le partage des connaissances : You build it, You run it (celui qui conçoit est aussi celui qui déploie), and You share it (et partage ses connaissances à travers des communautés de pratiques pour aligner les savoir-faire).
Par choix stratégique de l’entreprise, il arrive souvent que des applications fusionnent pour ne former qu’un seul et même outil. Si une seule usine logicielle ne gère pas initialement les applications, réévaluez le choix de l’usine pour réaliser les tests et se conformer aux risques de sécurité des différentes parties.
En revanche, il n’est pas nécessaire d’administrer plusieurs outils de gestion du code source sur le(s)quel(s) seraient raccordés le(s) pipeline(s).
Les possibilités sont nombreuses et la conception ne s’arrête pas à ces perspectives. Certains découpages seront plus favorables à l’entreprise en fonction de la maturité des équipes, de l’homogénéité des solutions, du budget, ou encore des enjeux métiers.
Pipeline CI/CD : Make or buy ?
Vaut-il mieux acheter une solution du marché, payer à l’usage, ou se créer sa propre pile technologique ?
Le choix relève d’une décision stratégique et est porté suivant plusieurs axes de réflexion :
La maturité de l’équipe DevOps : quel est le niveau d’expérience de l’équipe DevOps en place ?
Le nombre potentiel d’utilisateurs : vaut-il le coût de construire une UL pour une application à faible fréquentation ?
Les coûts de revient : combien l’UL va-t-elle coûter à l’année en termes d’infrastructure, de maintenance et d’exploitation ? Quel est le gain apporté en contrepartie ?
La compatibilité entre les outils pour une UL custom : un développement spécifique peut être nécessaire pour faire communiquer les outils entre eux
La capacité des logiciels et technologies à s’inscrire dans le temps
Ne sous-estimez pas l’effort et le coût nécessaire pour construire et maintenir un pipeline basé sur des logiciels open source (ex: GIT, Jenkins, SonarQube, Maven) : l’open source ne signifie pas nécessairement que c’est gratuit, mais que vous avez la possibilité de modifier et customiser le code source à votre convenance.
L’avantage d’utiliser une plateforme externalisée en mode PaaS ou SaaS (ex: Azure Devops, AWS CodePipeline, Google Cloud Build, GitLab) est de pouvoir immédiatement en tirer de la valeur. Certes, un outil propriétaire générera des coûts de licence ou d’utilisation, mais vous pourrez vous concentrer à 100% sur l’essentiel : délivrer de la valeur pour les métiers.
De plus, une solution orientée « As A Service » propose une chaîne d’outils “Tout-en-Un” et s’affranchit des risques d’obsolescence. Les mises à jour sont généralement transparentes pour les utilisateurs.
Les différences entre les logiciels open source et propriétaires vont bien au-delà de l’accessibilité du code source. Elles incluent également des éléments cruciaux tels que l’assistance technique, l’UX/UI, l’innovation, la sécurité et les coûts.
La réussite d’une organisation DevOps repose en grande partie sur une vision partagée à long terme et des ressources humaines et financières allouées à sa mise en place : auditez vos équipes et votre organisation !
Hébergement de l’UL : comment choisir entre On-Premise et Cloud ?
Pour identifier les applications de votre entreprise et celles éligibles à une automatisation, commencez par les localiser.
Selon la cartographie que vous établirez, une stratégie envisageable consisterait à mettre en place :
Une infrastructure DevOps On-premise pour déployer des applications hébergées sur site
Une infrastructure DevOps dans le Cloud pour déployer des applications également hébergées dans le Cloud
Cette option a notamment pour avantage de limiter la gestion des routes et des flux réseau.
Certains éditeurs proposent des solutions clé-en-main et gèrent la maintenance de l’UL à la place du client.
Même s’il peut y avoir des avantages à utiliser une plateforme “As A Service”, il faut néanmoins rester vigilant avant de se lancer. En effet, certaines peuvent couvrir plusieurs langages ou sont compatibles avec plusieurs fournisseurs Cloud, alors que d’autres vont chercher à vous verrouiller avec un fournisseur en particulier.
Aussi bien d’un point de vue de l’infrastructure que du logiciel, une étude est à mener et plusieurs éléments sont à prendre en considération.
Pour un outil propriétaire :
Veillez à la maturité de l’éditeur et de ses produits sur le marché, les services proposés, la couverture du support, le mode de licence et de tarification
Pour un outil open source :
Vérifiez leurs années d’existence, la communauté derrière ces logiciels et son degré d’investissement, la facilité pour monter de version et la stabilité des versions majeurs (fréquence de montée de version)
Pour les 2 types :
Contrôlez les systèmes d’exploitation supportés, la facilité d’installation et d’utilisation au quotidien (interface ‘user-friendly’), l’intégration avec les autres logiciels propriétaires ou open source, le type d’hébergement accepté (On-premise et/ou Cloud), l’accessibilité à l’UL par les différentes équipes internes et/ou externes
Organisez un REX : renseignez-vous auprès de votre réseau professionnel, mais également au sein de votre direction ou département. Il se pourrait qu’une autre entité de votre entreprise ait déjà installé une UL et qui corresponde à votre besoin ! Un retour d’expérience est une mine d’information qui pourra conforter ou orienter les décisions, évitant ainsi quelques études complémentaires à l’implémentation.
81 % des directeurs et acteurs IT pensent que les entreprises qui ne font pas du DEX une priorité seront distancées par leurs concurrents.
Avec l’évolution constante des technologies et le développement du travail à distance, les entreprises accordent de plus en plus d’importance à l’expérience digitale de leurs collaborateurs.
D’un point de vue collaborateur, les attentes vis-à-vis de leur environnement de travail ont également connu une transformation significative. Plusieurs facteurs doivent être pris en considération pour répondre aux nouvelles exigences et aspirations des employés.
D’après une étude d’Ivanti, 63 % des employés exercent une partie de leur activité en dehors du cadre traditionnel du bureau, et de ce fait, garantir une expérience numérique satisfaisante, sécurisée et efficace pour les collaborateurs devient un enjeu considérable pour la majorité des entreprises.
Comment peut-on définir la solution DEX et que peut-elle vous apporter ?
Gartner définit les outils de la Digital Employee Expérience, dite DEX comme une « évolution de la supervision de l’expérience digitale, de la gestion unifiée des terminaux (UEM) et des outils de monitoring et de gestion à distance”.
Dans un sens plus large, il faut considérer la DEX non seulement comme un outil mais comme une stratégie globale qui vient superviser, sécuriser et optimiser l’expérience numérique des collaborateurs.
Ils permettent aux équipes de la Digital Workplace (DWP) d’avoir une vue globale sur l’expérience digitale des employés et de mettre en place des stratégies centrées sur l’humain.
Tendances du marché
La Digital Employee Experience est une tendance majeure dans le monde professionnel. Les chiffres clés montrent l’importance croissante de la DEX dans la stratégie de transformation numérique des entreprises.
En effet, selon une étude Ivanti, 80 % des directeurs et acteurs IT interrogés considèrent la DEX comme un élément clé de leur stratégie de transformation numérique.
De plus, 81 % d’entre eux pensent que les entreprises qui ne font pas du DEX une priorité seront distancées par leurs concurrents.
Les enjeux de la solution DEX
Lorsque l’on évoque le Digital Employee Expérience ou également appelée Tour de contrôle, il est essentiel de comprendre les enjeux de cet outil au sein des entreprises.
Tout d’abord, la gestion de la DEX joue un rôle majeur dans
L’amélioration de la productivité et du bien-être des employés, en garantissant une expérience numérique et digitale fluide à la fois pour les collaborateurs métiers et IT. En minimisant les incidents majeurs ou en réduisant les frustrations liées aux interruptions des services IT, les employés perdent moins de temps à créer des tickets ou à solliciter l’aide de leurs collègues pour résoudre des problèmes techniques. Par ailleurs, il est aujourd’hui observé une augmentation du stress technologique chez les professionnels de l’IT, ce qui peut avoir des répercussions sur leur santé physique et morale. Selon une étude d’Ivanti, 61% des répondants affirment que des expériences technologiques négatives ont un impact sur leur moral, tandis que 68% déclarent ressentir un burnout au travail, souvent causé par une surcharge de notifications, d’outils et de connexions. Ainsi, l’accès à des outils et applications fiables, exempts de problèmes techniques frustrants, permet aux employés de se concentrer pleinement sur leurs tâches, favorisant ainsi leur productivité et leur capacité à se consacrer à des activités à forte valeur ajoutée.
Une réponse essentielle aux risques associés au manque de visibilité, en contrant une perspective IT qui se concentre principalement sur la détection et la résolution d’incidents, parfois au détriment de l’expérience utilisateur. Cette divergence entre la vision de l’IT et le vécu des utilisateurs peut engendrer des complications. En termes d’outils, la DEX offre une vue d’ensemble centralisée, de bout en bout sur les problèmes susceptibles de survenir pour les collaborateurs, depuis les postes de travail jusqu’aux systèmes en back-end.
En outre, le DEX favorise l’efficacité et l’agilité de l’entreprise. Grâce à une surveillance continue des appareils, des applications et des réseaux, les équipes informatiques peuvent détecter rapidement les problèmes potentiels. Les administrateurs sont alertés en temps réel en cas d’incident, ce qui leur permet de réagir immédiatement et de résoudre les problèmes de manière efficace. Cette réactivité contribue à réduire les temps d’arrêt et à maintenir une performance optimale de l’entreprise.
Enfin, l‘automatisation des actions IT est une autre caractéristique essentielle du DEX. Les outils DEX proposent des scripts préétablis et des fonctionnalités configurables qui permettent au service informatique de résoudre les problèmes de manière plus rapide et sans intervention manuelle. Cette automatisation renforce l’efficacité globale de l’entreprise en optimisant les processus et en évitant les retards inutiles.
La solution DEX offre une visibilité de bout en bout sur l’IT pour améliorer l’expérience digitale des employés :
Pourquoi faut-il opter pour une solution DEX ?
Pour choisir une solution DEX adaptée à ses besoins, il est essentiel de prendre en compte certaines fonctionnalités clés, notamment :
Supervision en continue : La solution doit être capable de surveiller en temps réel les appareils, les applications et les réseaux pour mesurer l’expérience réelle des employés.
Rapports et alertes : Les administrateurs doivent recevoir des rapports en temps réel et des alertes lorsqu’un problème survient, afin de pouvoir agir rapidement.
Scripts préétablis et fonctionnalités configurables : Ces outils permettent aux équipes informatiques de résoudre efficacement les problèmes et de personnaliser la solution en fonction des besoins spécifiques de l’entreprise.
Intégration avec la messagerie et les outils de résolution d’incidents : L’intégration avec ces outils permet une communication fluide avec les employés et une résolution rapide des problèmes.
Analyse des causes profondes : La solution doit être capable d’analyser les causes profondes des problèmes afin de faciliter leur résolution.
Collecte du feedback des employés : La possibilité de recueillir le feedback des employés via des enquêtes intégrées permet d’obtenir des informations qualitatives précieuses pour améliorer l’expérience digitale.
Capacité d’analyse comparative interne : Cette fonctionnalité permet de comparer les scores de l’expérience digitale des employés sur différentes applications, ce qui permet d’identifier les meilleures pratiques et les domaines à améliorer.
Zoom sur les cas d’usage du DEX
Accroître le digital expérience
Établir des mesures strictes sur le Digital Workplace Mesurer la perception qu’ont les collaborateurs de leur expérience technologique Mesurer la performance du réseau, des équipements et des applicationsIdentifier les tendances organisationnelles en termes d’adoption ou d’utilisation des technologiesEnrichir la définition de persona à travers l’intégration de données DEX
Réduire les incidents
Identifier les problèmes de performances non signalées et ainsi lutter contre les “Digital Friction” Identifier et suivre les tendances de performances des équipements avant la survenue de l’incident Identifier et remédier aux freins du télétravail, tel qu’un mauvais réseau Wifi
Augmenter l’efficience
Améliorer l’experience du service desk en facilitant la résolution précoce des incidents(shift left), par l’obtention de données pertinentes (utilisateur, équipement, etc)Identifiez avec précision tous les collaborateurs impactés par un incidentAméliorez l’expérience d’Onboarding des employés en utilisant les données du DEX pour déterminer les applications et services dont ils peuvent avoir besoin
Réduire les coûts
Supprimer les logiciels inutilisés et récupérer les coûts de licence Rightsizing des terminaux physiques et logiques Réduire la dette technique en supprimant les apps obsolètes qui ont été remplacéesIdentifier les opportunités de réduction de la consommation d’énergie
Accélérer les valeurs
Soutenir les programmes d’amélioration continue de l’ingénierie et des services.Identifier la performance de vos équipements et applications par rapport aux concurrents Identifier les opportunités de déploiementEvaluer l’impact du Digital Workplace sur le business
Exemple de cas d’usage : Travail hybride
Faisons un focus sur l’utilisation du DEX dans un contexte de travail hybride pour prévenir et réduire les incidents au sein d’une entreprise.
Alors que les modèles de travail hybride deviennent la norme, les organisations doivent offrir une expérience digitale cohérente, fiable et sécurisée à leurs employés. Les applications de communications unifiées font partie des applications les plus critiques dans ce modèle car impactent directement la productivité.
Les défis
Les employés ont de plus en plus d’attentes sur la qualité des services
Manque de visibilité sur les équipement et les menaces croissantes
Parmi les bénéfices pour ce cas d’usage:
Détection des interruptions lors de l’utilisation des logiciels de communication.
Analyse des méthodes de connexion des employés au réseau d’entreprise et leur impact sur l’expérience utilisateur.
Identification des applications de l’entreprise utilisées par les télétravailleurs.
Évaluation de l’impact de la latence, de la bande passante et d’autres paramètres sur l’expérience utilisateur.
Présentation d’analyses détaillées sur l’utilisation des logiciels de communication tels que MS Office ou MS Teams (par utilisateur, appareil ou version).
Repérage des applications et des systèmes d’exploitation nécessitant des mises à jour pour des raisons de sécurité et de conformité.
En conclusion
La DEX offre une sorte de tour de contrôle pour les équipes en charge du digital workplace en entreprise. Et en tant que tour de contrôle, elle se charge de collecter les informations relatives aux équipements, applications et autres ressources que l’on peut associer à l’IA pour permettre aux équipes IT d’agir de manière proactive dans la prise de décisions et améliorer l’expérience des collaborateurs.
Dans ce contexte en constante évolution, les entreprises doivent s’adapter pour répondre aux nouvelles attentes des collaborateurs.
En favorisant un mode de travail hybride, en mettant en place un cadre culturel et managérial propice à l’épanouissement des employés, et en offrant une expérience digitale exemplaire, les entreprises seront en mesure d’attirer et de retenir les talents clés.Reconnaître la valeur de chaque collaborateur et placer son bien-être au cœur des préoccupations permettra aux entreprises de prospérer dans un environnement compétitif tout en renforçant l’engagement et la loyauté de leurs équipes. Le Digital Employee Experience est ainsi un levier essentiel pour assurer la réussite de l’entreprise dans cette nouvelle ère du travail.
Stoplight est un outil de conception d’API qui permet aux développeurs de créer, de documenter et de tester des API de manière efficace et collaborative. Il embarque les fonctionnalités que l’on retrouve en partie sur les outils accélérateurs de développement d’API tels que Postman, SoapUI ou encore l’écosystème Swagger.
Quelles sont les caractéristiques spécifiques de l’outil et ses limites le cas échéant ?
Comment se positionne-t-il par rapport à des outils implémentant des fonctions comparables ?
Pexels – Thisisengeneering
Étape 1 : Créer un nouveau projet
Stoplight permet de créer de nouveaux projets sous la spécification OpenAPI. A noter que GraphQL ou AsyncAPI ne sont pas encore supportés. L’outil pouvant s’interfacer avec GitLab, GitHub, BitBucket ou encore Azure DevOps, il est aussi possible d’importer des projets existants.
Étape 2 : Définir l’API
Une fois le projet créé, il faut maintenant définir notre API. Il est possible soit de la créer (fichier format JSON ou YAML), soit d’importer un fichier de spécification OpenAPI, ou une collection Postman. Diverses versions d’OpenAPI sont supportées (2.0, 3.0 et 3.1 à l’heure de la rédaction de cet article).
On pourra définir des modèles d’objets communs à notre projet ou spécifiques à une API. L’édition des endpoints, des paramètres et des réponses se fera facilement soit en utilisant la vue formulaire, soit la vue code, dans tous les cas avec une preview en temps réel.
Pour bien garder à jour notre projet, en se branchant par exemple à GitHub, il est possible de configurer les échanges souhaités et ainsi de mettre à jour l’API à chaque changement de Git et vice-versa.
Étape 3 : Linter l’API
Le linting d’une API est une analyse de son code pour faire remonter des erreurs, warnings et incohérences, à la manière d’un compilateur.
Stoplight propose des style guides de linting par défaut qu’on peut ensuite modifier ou importer. Ces règles seront utilisées pour l’outil de linting intégré basé sur Spectral.
Cela permet de vérifier que la définition de l’API correspond aux bonnes pratiques du marché et aux méthodes spécifiques à l’entreprise.
La configuration du linting est évidemment modifiable à souhait. On pourra ainsi garantir plus facilement une cohérence accrue entre des API qui auraient été faites par diverses personnes, ainsi que réduire le nombre d’erreurs. D’où finalement une API de meilleure qualité.
Étape 4 : Documenter l’API
La documentation de l’API dans Stoplight est gérée via le composant open source Elements intégré à la plateforme. Suivant la spécification OpenAPI, on pourra facilement créer la documentation des endpoints, des réponses, le tout avec un environnement interactif et non figé.
De plus, Stoplight supporte les fichiers Markdown (dans l’onglet Docs) permettant de documenter l’API davantage. Cela offre la possibilité d’y intégrer du contenu non textuel : tableaux, images, diagrammes Mermaid ou contenu d’autres sites (Twitter, Youtube, Giphy, Spotify, etc.). La documentation n’en sera que plus riche et la découverte de votre API facilitée, d’où une meilleure adoption.
Étape 5 : Tester, sécuriser et déployer l’API
Il est possible de tester l’API à l’aide de fonctionnalités nativement intégrées dans l’outil. Ainsi la vérification de contrat sera t-elle automatique via le cross checking de la spécification Open API.
Stoplight propose une interface à travers laquelle écrire et exécuter des tests pour évaluer la réponse de chaque endpoint et méthode. Il est également possible d’utiliser le module Prism pour simuler les appels, dans un environnement de test minimal intégré.
La plateforme supporte les méthodes d’autorisation OAuth2 et OpenIDConnect. L’outil met à disposition une interface dans laquelle il est ainsi possible de déclarer la modalité de contrôle utilisée, le flow et les paramètres évalués (clé d’API, token, credentials)
Enfin l’outil intègre également l’utilitaire de ligne de commande NPM et permet de pousser les mises à jour d’une API sur l’interface de navigation de Stoplight. L’API sera alors sur le Studio Web.
Étape 6 : Générer du code
Une fois l’API testée et validée, vous pouvez utiliser Stoplight pour générer du code serveur et client à partir de votre définition d’API. En effet la plateforme est équipée d’un générateur de code (stubs serveur, configuration…) supportant plusieurs langages de programmation (notamment Java, JavaScript…).
Les capacités de Stoplight à l’heure de la rédaction de cet article sont cependant plus focalisées sur la documentation et les features de collaboration, et sont plus limitées sur la génération de code que celles d’un Swagger Codegen par exemple.
On peut noter pour conclure que Stoplight est un outil avec une couverture relativement large des fonctionnalités de conception et de construction d’une API. Il supporte également les standards d’implémentation en la matière (norme OpenAPI, flux de sécurisation avec OAuth et OIDC…).
Il répond de manière plus complète à des besoins en amont de conception et de développement. Cependant, il présente des limites. Il offre également une couverture moins importante sur des fonctions plus aval, telles que la publication et le contrôle plus fin d’accès à des ressources exposées par API.
Dans les précédents volets, nous avons expliqué ce qu’est une architecture MACH et dans quels cas elle exploite tout son potentiel.
Dans cet article nous allons décrire les 5 points fondamentaux à la mise en place d’une architecture MACH dans un contexte legacy.
Définir le parcours utilisateur et les points de bascule
Le parcours utilisateur est naturellement le point de départ de la création d’une architecture web, mais dans quelle mesure il me permet de la définir et de la concevoir ?
L’identification des différents points de bascule est primordiale pour identifier le découpage de l’architecture. Le “point de bascule” est une étape dans le parcours client qui nous permet de passer d’un contexte fonctionnel à un autre.
Pour identifier les points de bascule, pensez données
Le point important à retenir, pour assurer un bon découpage de l’application, est que ma donnée peut passer de mon navigateur (micro front-end) à mon application back-end (micro-service) jusqu’à mon back-office (SAP, etc.) sans avoir des dépendances et des liens qui se croisent. En gros, un micro-service qui fait appel à un autre micro-service, n’est plus un micro-service.
Pour cela, nous devons bien identifier les données impliquées dans chaque étape.
Bien que nous ayons des données qui semblent similaires, le découplage est garanti : l’information du panier n’est pas forcément persistée, c’est un “brouillon” de ma commande que je vais abandonner une fois qu’elle sera confirmée, il aura donc un cycle de vie différent avec une “fin de vie” au moment de la création de la commande.
Si nous voulons faire du micro-service, nous devons réfléchir au découpage des micro-services
Quand on parle de mise en place d’une architecture MACH, avec des back-office legacy, alors le découpage doit être adapté au contexte applicatif.
L’utilisation de la logique DDD (Domain Driven Design) ne doit pas s’abstraire de l’implémentation car quand on parle micro-service on parle bien de domaine métier mais également d’indépendance, etc. des principes qui découlent de choix d’implémentation.
Nous devons donc analyser les applications legacy et identifier les interactions qui seront nécessaires.
Ce découpage logique, simple, va créer le découplage entre mon application web, mon site eCommerce, et mes back office legacy, tout en exploitant leur potentiel et en créant des verticaux liés par le processus et indépendants dans leur conception et déploiement.
Penser déploiement et cloud-first
Bien que le Cloud ne soit pas une condition sinequanone, ces architectures se prêtent bien à un déploiement Cloud.
Les services managés des cloudeurs s’adaptent bien à ce type d’architecture. Nous pouvons parler ici de serverless (ex. AWS Lambda, Google Cloud Functions, etc.), de la containerisation dynamique (ex. AWS Fargate, Azure Containers) ou, bien que moins intéressant, de la simple virtualisation.
Mais attention, les systèmes legacy ne sont pas forcément scalables autant que nous le souhaiterions. Penser à la chaîne complète des intéractions n’est pas un luxe. Dans certains cas l’échange avec ces outils peut réduire notre potentiel de montée en charge.
Dans ces cas, pensons découplage front-office / back-office.
Voici deux cas de figure et des solutions possibles :
L’architecture MACH s’avère être une solution hautement pertinente pour les entreprises souhaitant accroître leur agilité et améliorer leur réactivité technologique. Malgré les défis que son adoption peut poser, notamment dans des contextes dominés par des systèmes hérités, les bénéfices en matière de personnalisation, de performance et de gestion de l’infrastructure sont incontestables. Les organisations doivent soigneusement évaluer leur capacité à intégrer cette architecture, en considérant leur environnement technique actuel et leurs objectifs futurs.
