Plongée au cœur de la DevX !

DevX – Xpérience du développeur – qu’est-ce que c’est précisément ? y a-t-il plusieurs définitions du sujet ?

L’expérience DevX est une philosophie au carrefour du développement, du management, du business, des RH : Il existe de multiples définitions de la devX (expérience du développeur) mais elles se rejoignent toutes sur deux grands axes : la satisfaction des développeurs et leur efficacité/productivité.

Lorsqu’une entreprise met en place une démarche DevX au sein de son organisation, l’objectif est de trouver des solutions pour que les développeurs puissent exercer leur métier dans les meilleures conditions, avec les meilleurs outils. La DevX, c’est en quelque sorte, mettre le développeur au cœur de son entreprise. Autrefois perçu comme un exécutant parmi tant d’autres, peu d’attention lui était portée. “Mais ça, c’était avant”, comme dit l’expression. Aujourd’hui, les développeurs sont la pierre angulaire, les catalyseurs de l’innovation des entreprises. Dans un contexte où la guerre des talents fait rage, mettre ses développeurs dans les meilleures conditions pour produire du code de qualité, le plus rapidement possible, est un facteur clé de rétention et un avantage concurrentiel non négligeable. 

Les définitions de la DevX dépendent aussi et surtout du contexte du développeur et de la taille de l’entreprise. Par exemple, dans certaines scale up, la problématique majeure sera de pouvoir tester une nouvelle fonctionnalité dans tout l’écosystème technique de l’entreprise, ce qui n’est pas forcément possible en local quand il existe une trentaine d’applications qui communiquent entre elles et c’est à ce moment-là que les environnements de développement à la volée arrivent sur la table notamment. Tandis que d’autres entreprises auront davantage de problématiques autour de leur CI/CD (l’intégration continue) car si pour tester dans un environnement Cloud, un développeur doit attendre 30 min pour tester une fonctionnalité, il sera à la fois inefficace et frustré par cette lenteur. 

Et la DevX concerne tous les domaines ? 

Oui, cela concerne tous les domaines de la tech. Cela peut aller du développeur web pour qu’il puisse implémenter de nouvelles fonctionnalités sur un site web rapidement de manière sereine jusqu’au data engineer qui lui, va avoir besoin d’un workflow efficace pour tester ces processus d’analyse de données qui sont assez lourds en général.

C’est un des enjeux clés du métier de DevOps : mettre les développeurs dans les meilleures conditions pour produire vite du code de qualité. Le développeur est considéré comme un utilisateur, dont on écoute les retours et avec qui on met en place une démarche d’amélioration continue.

Dans une grande structure, les enjeux de validation ou de gestion des données critiques rendent forcément l’expérience de développement plus lourde, il devient alors essentiel d’avoir une démarche consciente pour faciliter le travail des équipes techniques au quotidien. Toute la problématique est d’optimiser cette expérience en fonction du contexte de l’entreprise. 

Alors, finalement la DevX, c’est prendre soin des développeurs. Pourquoi est-ce un sujet crucial aujourd’hui pour vous ? 

En 2022, les missions “DevX” représentent un quart des projets, un chiffre en forte progression par rapport à 2021. Start up comme grands groupes sont en recherche de solutions pour améliorer les conditions de travail techniques des développeurs. En tant que DevOps c’est notre mission car ce sont les premiers utilisateurs d’une infrastructure Cloud. Nous devons alors échanger avec les développeurs pour voir ce qui les bloque ou les ralentit.

S’il faut deux jours pour générer un environnement de test afin que le développeur puisse tester une fonctionnalité, c’est extrêmement pesant pour lui car il a deux options : attendre longtemps et faire exploser son projet, ou prendre le risque de mettre en production sans tester son code et donc faire bugger son application. La génération automatisée d’environnements de test est alors une solution envisageable pour débloquer la situation.  Autre exemple, nous allons souvent déployer des composants comme des bases de données que nous mettrons à disposition des développeurs pour qu’ils puissent faire leurs tests avec tous les composants nécessaires au bon fonctionnement de leur application. Dans ce cas, les devs seront forcément plus sereins que s’ ils ne pouvaient pas tester avec toutes les dépendances externes de leur application.

Le conseil que je donnerais à une entreprise qui souhaite se lancer dans une démarche DevX : il ne faut pas se lancer dans une grande liste au Père Noël des meilleures pratiques DevX. C’est une démarche sur-mesure, car chaque équipe technique a ses propres contraintes et ses propres process.

Pour démarrer, il faut créer une coopération entre “utilisateurs” (développeurs) et fournisseurs (DevOps), définir les points bloquant pour les développeurs, et établir une stratégie étape par étape qui lève les points bloquants des développeurs.

Plusieurs petits chantiers successifs fonctionnent toujours mieux qu’un grand “big bang DevX”.

Smart DSI N° 28