[J-Story 2] Craft, DevEx et performance engineering : Remettre la maîtrise au cœur du développement. Anis Chaabani – Coach Craft Indépendant @TotalEnergies Digital Factory

Pourquoi cette J-Story ?

Dans cette édition, on parle de performance engineering, de craft et d’IA… mais surtout de posture professionnelle.

Comment faire évoluer une organisation vers plus de maîtrise, plus de clarté et plus d’impact, en travaillant sur l’alignement et l’expérience développeur plutôt qu’en ajoutant des couches de process.

Pourquoi lire ça ?

Parce que la performance ne se résume pas à des métriques.

Cette J-Story partage un retour terrain concret sur ce qui fait réellement la différence : Developer Experience, alignement métier-tech, pratiques d’ingénierie solides et responsabilité professionnelle.

Ce que vous allez apprendre ?

• Pourquoi “savoir coder” ne suffit pas : le craft comme socle de professionnalisme
• Comment utiliser le DDD comme levier d’alignement plutôt que comme patterns théoriques
• Pourquoi améliorer la DevEx est souvent plus puissant que chercher à mesurer la performance brute
• Pourquoi l’IA rend la maîtrise encore plus critique (pilote automatique ≠ pilote)

À qui cette J-Story s’adresse-t-elle ?

Engineering Managers, VP Engineering, responsables DevEx / Platform / Delivery, Tech Leads, CTO, et toutes les équipes qui cherchent à améliorer durablement leur performance sans sacrifier la qualité ni la cohérence produit.

1. Peux-tu présenter ton parcours jusqu’à aujourd’hui ?

Je suis Anis, j’ai plus de 20 ans d’expérience dans le digital, et depuis environ un an, je suis Coach Craft à la Digital Factory de TotalEnergies (TDF).
Je suis tombé dans l’informatique très tôt. Vers 12,13 ans, mon père m’achète une machine qu’il pense être “une console de jeux”… sauf que c’était plutôt un ordinateur type Commodore, à brancher sur un écran, avec des cassettes de jeux. J’ai joué un peu, je me suis vite ennuyé… et je suis tombé sur un livre de programmation fourni avec la machine. J’ai commencé à lire, à faire les exercices, à coder. Et ça ne s’est jamais arrêté. Je codais pour tout : des petits programmes, des idées, même des trucs pour m’organiser, et au lycée j’ai même vendu mon premier logiciel à une entreprise.

Ensuite j’ai fait des études en informatique appliquée à la gestion (diplômé en 2005). J’ai eu la chance de démarrer dans un petit éditeur logiciel, une équipe de 5 développeurs, déjà très “craft” à l’époque. Ils pratiquaient l’Extreme Programming : TDD, itératif/incrémental, collaboration directe avec le client, user stories, etc. Ça a été une expérience fondatrice : je savais coder, mais j’ai compris que coder ne suffit pas. Il y a une manière professionnelle de construire du logiciel.

Après ça, je suis parti en banque, chez Euro-Information (Crédit Mutuel CIC), pendant une dizaine d’années. Là, changement de décor : waterfall, process, standards, silos, frameworks maison. J’y ai évolué de développeur vers un rôle de chef de projet technique, proche de ce qu’on appellerait aujourd’hui engineering manager : management d’équipe, mais aussi conception, dev, architecture. Et, sans m’en rendre compte au début, j’avais déjà une posture très “coaching” : faire grandir les gens, construire une équipe solide, aider à mieux délivrer.

À un moment, j’en ai eu marre de “batailler” tout seul sans support réel du management. Et j’ai mis un mot sur ce que je voulais faire : du coaching.

Par la suite, je me suis orienté vers le consulting, en effectuant des missions de coaching agile, orga et craft sans jamais laisser tomber ma casquette technique qui pour moi reste la base de notre métier.

2. Pourquoi avoir basculé vers le coaching ? Qu’est-ce que tu cherches dans ce rôle ?

Ce qui me tient le plus à cœur, c’est d’apprendre en continue, de transmettre et de faire grandir les autres au même temps.
Je l’ai vécu moi-même : au début de ma carrière, j’ai eu la chance d’être accompagné par des développeurs très seniors, très solides sur les pratiques et la culture, qui m’ont vraiment fait passer un cap. J’avais envie de rendre ça à mon tour, et de le faire de façon impactante.

Et puis il y avait une limite claire au management : tu as de l’impact, mais souvent sur une équipe, parfois deux ou trois. Le coaching, ça a été une libération : un rôle plus transversal, plus systémique. Je peux aller là où ça fait mal, aider à clarifier, rendre les actions pérennes, et surtout rendre les équipes autonomes pour qu’elles continuent sans moi… et qu’elles transmettent à leur tour.

Ce que j’adore, c’est l’effet “long terme” : des gens que j’ai accompagnés bougent, changent d’équipe, changent d’entreprise, et réappliquent ce qu’on a construit ensemble. Certains reviennent des années après pour dire merci. Ça, c’est énorme.

3. Pour toi, c’est quoi le craft (et donc le coaching craft) ?

Avant de parler de coaching craft, je reviens toujours au craft.
Le craft, c’est d’abord une posture professionnelle du développement logiciel. Prendre ses responsabilités : livrer un produit qui répond au besoin, qui apporte de la valeur, et qui tient dans le temps. Pas du jetable.

J’utilise souvent une analogie simple : une cuisine IKEA vs un artisan cuisiniste. IKEA, c’est standardisé, ça marche, mais tu as des contraintes : tu ne mets pas le lave-vaisselle où tu veux, tu ne changes pas ce que tu veux, tu fais avec la gamme. L’artisan, lui, s’adapte à tes besoins, te conseille sur ce qui va durer, modifie si besoin l’électricité, l’eau, le plan de travail… bref, il prend la responsabilité du résultat.

En logiciel, c’est pareil : on peut aller vite en bricolant, mais ça coûte toujours plus tard. Le craft, c’est le socle qui permet de livrer correctement et durablement.

Le coaching craft, c’est aider les équipes et l’organisation à monter en professionnalisme, sans faire à leur place. On identifie les douleurs, on apporte de la clarté, on met les bons leviers, et on installe des pratiques qui tiennent dans le temps.

4. Peux-tu partager une mission marquante où tu as “fait tomber la pression” et amélioré la performance ?

Ma mission la plus marquante, c’est ma première mission en tant que coach (casquette Scrum Master) chez Enedis.

Quand j’arrive, c’est le chaos. Un produit en développement depuis 2 ans, plusieurs tentatives de mise en prod ratées, et une pression énorme. Le middle management enchaîne les réunions “pour comprendre pourquoi ça ne marche pas”, ce qui empêche l’équipe… de travailler.

Je prends du recul et je vois des problèmes partout : organisation, fatigue, architecture, données, sources non fiables.

Le point clé, c’est la posture : le management s’attendait à une mise en prod “demain” tous les jours. Je leur demande 2 mois avant une communication officielle d’ouverture du service. Ils acceptent, simplement parce que personne ne l’avait proposé clairement.

Pendant ce délai, on baisse la pression, on redonne du temps de travail réel, on restructure, on corrige l’architecture, on traite les sources de données, on redonne le pouvoir de décision à l’équipe de dev. Et surtout : on redonne de la visibilité au management.

Résultat : une mise en prod réussie quelques semaines après. Et là, switch immédiat : la pression tombe, la confiance revient, l’équipe recommence à respirer. Les gens rigolent à nouveau, mangent ensemble, apprennent, partagent, mélangent les rôles, cassent les silos. Une équipe qui voulait fuir le projet devient une équipe soudée, presque une famille. Et je suis encore en contact avec eux aujourd’hui.

Ce que ça montre : ce n’est pas “le micro-management” qui résout le problème. C’est créer les conditions pour travailler mieux.

L’expérience développeur c’est aussi donner la liberté et le pouvoir de décision aux développeurs pour faire les bons choix, faire leur métier sans les freiner.

5. Tu parles souvent de communautés de pratique. Tu peux définir et expliquer pourquoi c’est aussi puissant ?

Créer une communauté de pratique, c’est créer un groupe qui se retrouve régulièrement pour partager : pratiques, retours d’expérience, présentations, coding dojos, apprentissages.

L’impact est systémique : des standards émergent naturellement, sans être imposés “par autorité”. Ça valorise aussi les développeurs : ils ne sont plus juste “derrière l’écran”, ils deviennent visibles, porteurs de pratiques, référents.

Et ça change des trajectoires : des personnes peu motivées deviennent moteurs, certaines commencent à faire des conférences, et même côté recrutement, c’est un atout fort (on en parle en entretien : “ici on apprend, on partage, on a une communauté”).

J’ai presque toujours contribué à la mise en place ou à l’animation des communautés de pratiques dans toutes mes missions et expériences. Les plus marquantes c’était la Craft Academy chez Natixis ou encore la Craft Community chez Allianz France qui à eu un succès et un rayonnement important au sein de l’entreprise.

Ces communautés locales aux entreprises ont aussi étaient un tremplin pour pas mal de personnes pour changer leur façon de voir le métier de développement logiciel et parfois viser de nouveaux rôles ou encore donner des conférences à l’externe.

6. Le DDD : comment tu le définis simplement, et comment tu l’appliques en entreprise ?

Le DDD vient du livre d’Eric Evans en 2005. Son objectif : gérer la complexité du développement logiciel.

Ce que j’utilise le plus en entreprise, ce n’est pas “réciter le bouquin”. C’est créer un alignement fort entre métier et tech, via un langage commun (ubiquitous language) et une compréhension partagée du système.

Concrètement, je commence souvent par des ateliers type Event Storming : métier, dev, test, tout le monde ensemble. Mon objectif au départ, c’est de faire sortir les zones de flou. Je veux presque “plein de post-its rouges” : ambiguïtés, incompréhensions, questions sans réponse. Ça crée un sentiment d’urgence sain : on ne peut pas construire proprement si même le métier ne peut pas répondre à certaines questions.

Et ensuite, on avance itérativement : une zone à la fois, puis on descend dans le code, avec les bons patterns, le bon découpage, les bounded contexts quand l’organisation est prête.

Et souvent, au début, je ne dis même pas “DDD”. Je parle d’alignement, de langage commun, de clarification. Le label vient après, quand les équipes veulent savoir “d’où ça vient”.

7. Flow, craft, DDD : tu les mets dans la même famille ?

Oui, parce que ça se rejoint. Quand on parle flow, on parle de processus : visualiser, mesurer, identifier où ça bloque, et fluidifier.

Ce que je fais presque toujours en premier, c’est visualiser. Pas seulement le flux de delivery : la dette technique, le release management, les compétences, les dépendances, la compréhension du système.

Ensuite, j’utilise la boîte à outils selon le blocage :
si ça bloque au déploiement, on va travailler tests, CI/CD, pratiques d’ingénierie ;
si ça bloque parce qu’on ne livre pas ce que veulent les utilisateurs, on va travailler alignement métier-tech, DDD, clarification.

Le craft, c’est une boîte à outils qu’on ouvre au bon moment, avec les bons “coups de tournevis”.

8. Comment tu réponds à l’opposition “craft vs time-to-market” ?

Déjà, j’évite souvent de parler “craft” au business. Je parle leur langage.

Je responsabilise chaque partie : le business exprime le besoin et la valeur attendue. L’équipe de dev est responsable de livrer correctement, avec la qualité nécessaire.

Je ne demande jamais au business d’arbitrer “qualité vs vitesse”. Ce n’est pas la bonne question. La qualité est intrinsèque : quand un utilisateur reçoit une fonctionnalité, il veut qu’elle fonctionne, aujourd’hui et demain.

Si la vitesse ne convient pas, ce n’est pas “on dégrade la qualité”. C’est un autre sujet : périmètre, organisation, dispositif, dépendances, outillage. Il y a plein de leviers, mais pas celui-là.

9. IA : est-ce que ça tue le craft, ou est-ce que ça le rend encore plus important ?
 

Pour moi, ça le rend encore plus important.

Tout le monde peut mettre le pilote automatique. Mais il faut un pilote dans l’avion.

L’IA peut produire du code très vite. Mais si le développeur ne maîtrise pas les pratiques, l’architecture, le raisonnement, il ne saura pas guider, valider, corriger, reprendre la main. Il accepte des propositions qu’il ne comprend pas… et ça finit en hallucinations, en architecture bancale, en dette massive.

Les développeurs “exécutants” risquent clairement d’être remplacés. Mais ceux qui maîtrisent vraiment leur métier vont utiliser l’IA comme un accélérateur énorme. Moins de temps sur la syntaxe, plus de focus sur la conception, la qualité, l’alignement, la responsabilité.

10. Tu dis qu’il ne faut pas commencer par “mesurer”, mais par “améliorer les conditions”. Pourquoi ?

Parce que mesurer la performance en engineering est extrêmement complexe : est-ce que le problème vient de l’équipe, de l’écosystème, de la culture, du besoin, des dépendances, du delivery, de l’outillage ? Il n’y a pas de métrique universelle.

Mon approche : plutôt que de fantasmer des KPI, je travaille sur la Developer Experience. On enlève les frictions, on outille, on crée des golden paths, des plateformes, on installe des standards qui émergent via les communautés, on réduit la charge mentale.

Ça crée un cercle vertueux : mieux travailler → plus de fluidité → meilleure performance. Et c’est observable rapidement.

11. Si tu devais résumer ton métier en une phrase ?

Mon job, c’est être un levier qui permet d’aligner l’excellence technique avec la performance organisationnelle : moins de dettes invisibles, un flow plus fluide, et des équipes capables de faire évoluer leur produit sans peur.

—————————————————————————————————-

Ce qu’on retient de cette J-Story

• Le craft est avant tout une posture professionnelle
• La Developer Experience est souvent le premier levier de performance
• L’alignement métier-tech est essentiel pour gérer la complexité
• Les communautés de pratique font émerger des standards durables
• Avec l’IA, la maîtrise de l’ingénierie devient encore plus critique

J-Story 2 / Mars 2026 / Anis Chaabani (TotalEnergies Digital Factory)

—————————————————————————————————-

Un grand merci à Anis Chaabani pour ce témoignage.
Chez Jissen, nous accompagnons les organisations qui veulent améliorer durablement la performance de leurs équipes d’ingénierie. Craft, Developer Experience, performance engineering ou alignement métier-tech : nous intervenons auprès des équipes pour renforcer les pratiques, fluidifier le delivery et construire des organisations capables de livrer vite, bien et dans la durée.
Si ces sujets résonnent avec vos enjeux après la lecture de cette J-Story, nos équipes seront ravies d’échanger avec vous.