Depuis des mois, chez EKITE, nous avons en tête deux éléments bien intégrés à notre stratégie d’entreprise : la souveraineté numérique et le Numérique Responsable.

De mon côté, par rapport à ma capacité d’accompagnement, il y a eu beaucoup de réflexion autour de la deuxième thématique. J’avais noté quelques notes dans un coin de mon carnet numérique disponible sur le nuage. L’idée était de reprendre des artéfacts existants et de les saupoudrer de nouveaux angles fondés sur ma récente prise de conscience sur notre responsabilité en tant qu’acteurs du numérique.

Alors j’ai travaillé sur plusieurs items classiques dans le Product Management. Vous le savez, j’aime le partage, alors voici deux reboots d’artéfact qui pourraient vous aider à adopter les bons réflexes sur vos produits numériques.

Product Vision Board NR

Le Product Vision Board, comme son nom l’indique, est un tableau qui formalise la vision d’un produit, en développant plusieurs axes complétant cette vision : population cible, besoins et solutions, mesures.

Voici une version qui intègre l’angle du Numérique Responsable.

Source du format graphique : https://canva.link/mzfy2ljskdvlaxd

DOR/DOD x RGESN

Les DOR (Definition Of Ready) et DOD (Definition Of Done) sont deux éléments nécessaires pour cadrer votre workflow et optimiser la réalisation dans une équipe.

Si vous ne connaissez pas, voici deux ressources pour pallier cela. DOR Kards & DOD Kards.

J’aime beaucoup ces checklists qui peuvent aider les équipes, sauf que je trouve qu’elles sont généralement très orientées et sont poussiéreuses par rapport au Numérique Responsable.

Le RGESN est le Référentiel général d’écoconception de services numériques. C’est un ensemble de règles à respecter dans une démarche d’écoconception.

J’ai décidé de prendre deux éléments et de les fusionner pour qu’une équipe puisse embarquer les bonnes pratiques de l’écoconception directement dans son mode de fonctionnement.

Ces critères intègrent les bonnes pratiques d’écoconception, tout en restant alignées sur les 3U (utiles, utilisables, utilisés).

? Definition of Ready NR (DoR)

Une user story ou une tâche est considérée comme « prête » si elle respecte les critères suivants :

1. Utilité et Pertinence (RGESN – Critère 1.1)

• La user story répond à un besoin réel et validé (études utilisateurs, personas, ou feedbacks).
• Elle est alignée avec au moins un Objectif de Développement Durable (ODD) ou une limite planétaire (ex. : réduction des émissions de CO?).
• Une analyse d’impact a été réalisée pour vérifier que la fonctionnalité crée plus de valeur qu’elle n’en détruit (ex. : gain utilisateur vs coût environnemental).
• On a vérifié qu’aucune solution existante (interne ou externe) ne répond déjà à ce besoin.

2. Cibles et Besoins (RGESN – Critère 1.2)

• Les utilisateurs cibles (primaires et secondaires) sont clairement définis.
• Les attentes et contraintes des utilisateurs sont documentées (ex. : accessibilité, performance).
• La user story est priorisée en fonction de son ratio impact/ressource (ex. : méthode MoSCoW ou YAGNI).

3. Contraintes Techniques et Environnementales

• Les contraintes techniques (ex. : compatibilité avec des appareils anciens) sont identifiées.
• Les contraintes environnementales sont prises en compte :
  • Poids maximal de la fonctionnalité (ex. : < 500 Ko pour une page web).
  • Temps de chargement cible (ex. : < 1 s).
  • Hébergement vert confirmé (data center alimenté par énergies renouvelables).
• Les données nécessaires sont minimisées (RGPD + écoconception).

4. Critères d’Acceptation
   • Les critères d’acceptation incluent des métriques environnementales (ex. : score EcoIndex > 80/100).
   • Les critères d’accessibilité sont définis (ex. : respect des WCAG 2.2).
   • Les tests de performance (ex. : temps de réponse, consommation énergétique) sont planifiés.

? Definition of Done NR (DoD)

Une user story ou une tâche est considérée comme « terminée » si elle respecte les critères suivants :

1. Fonctionnalité et Utilité

• La fonctionnalité est implémentée et testée selon les critères d’acceptation.
• Elle répond strictement au besoin sans ajouter de fonctionnalités inutiles (principe YAGNI).
• Elle est documentée (pour les utilisateurs et les développeurs).

2. Écoconception (RGESN – Critères Techniques)

• Poids et performance :
  • Le poids de la fonctionnalité est ? au seuil défini (ex. : < 500 Ko).
  • Le temps de chargement est ? à la cible (ex. : < 1 s).
• Efficacité énergétique. :
  • Le code est optimisé (pas de libraries inutiles, algorithmes légers).
  • Les requêtes serveurs sont minimisées (ex. : lazy loading, cache).
• Hébergement :
  • La fonctionnalité est déployée sur une infrastructure verte (data center alimenté par énergies renouvelables).

3. Accessibilité et Inclusivité

• La fonctionnalité respecte les normes WCAG 2.2 (niveau AA minimum).
• Elle est testée sur des appareils anciens (ex. : smartphones 5 ans, navigateurs non récents).
• Elle est compatible avec les technologies d’assistance (ex. : lecteurs d’écran).

4. Données et RGPD

• Minimisation des données :
  • Seules les données strictement nécessaires sont collectées.
  • Les données sont stockées le moins longtemps possible.
• Transparence :
  • Les utilisateurs sont informés de la collecte et de l’usage des données.
  • Un mécanisme de consentement explicite est en place (opt-in).

5. Mesure d’Impact

• L’empreinte environnementale de la fonctionnalité a été évaluée (ex. : score EcoIndex, ACV simplifiée).
• Les métriques de performance (ex. : temps de réponse, consommation CPU) sont documentées.
• Les améliorations possibles pour réduire l’impact sont identifiées et priorisées.

6. Documentation et Transparence

• La fonctionnalité est documentée dans le backlog ou le wiki de l’équipe.
• Une déclaration d’écoconception est mise à jour (si applicable).
• Les choix techniques (ex. : pourquoi un algorithme plutôt qu’un autre) sont justifiés.

7. Revue et Validation
   • La fonctionnalité a été revue par l’équipe (code review, tests utilisateurs).
   • Elle a été validée par le Product Owner et le référent écoconception (si applicable).
   • Les feedbacks utilisateurs (si disponibles) sont pris en compte.

Vous pouvez retrouver la version graphique complète ici : https://canva.link/lbgfcl0loax2dzb

Il existe beaucoup d’autres choses à faire pour intégrer le Numérique Responsable dans votre organisation.

Si vous désirez aller plus loin, contactez-nous pour discuter d’une formation complète autour du Product Management Responsable.

On en parle ?

Johan

Source picto & photos (image d’entête) : https://thenounproject.com/

Two unrecognizable female students holding handmade globe world earth by David Pereiras from https://thenounproject.com/photo/two-unrecognizable-female-students-holding-handmade-globe-world-earth-499VOE (CC BY-NC-ND 2.0)

L’article Ajoutez du Numérique Responsable dans votre Product Management est apparu en premier sur EKITE.

Il s’agit d’un exercice visuel et collaboratif où les équipes cartographient leurs interactions avec d’autres équipes en utilisant la métaphore des îles et des ponts. Chaque pont représente une connexion ; des briques indiquent la qualité de la relation (vertes, orange, rouges, violettes) ainsi que la responsabilité de son amélioration.

Pourquoi animer cet atelier ?

• Clarifier les dépendances : identifier avec quelles équipes vous interagissez et de quelle manière.
• Évaluer la qualité de la collaboration : mettre en évidence les connexions solides, faibles ou manquantes.
• Responsabiliser : désigner les responsables de l’amélioration des relations.
• Encourager l’amélioration continue : transformer les constats en engagements concrets assortis d’échéances.
• Renforcer le travail d’équipe : favoriser la transparence et la communication proactive entre les équipes.

Comment ça marche ?

Votre équipe est représentée par l’île centrale.

Autour de vous, vous voyez d’autres îles : ce sont les équipes avec lesquelles vous interagissez !

L’objectif

Créer des liens entre votre île et les îles environnantes. Construisez des ponts !

L’animateur présente l’atelier pour en expliquer le but :

« Votre équipe est représentée par l’île centrale. Autour de vous se trouvent d’autres îles ! Et sur chaque île, une équipe.

Votre objectif : identifier avec quelles autres îles vous interagissez et, surtout, comment. Pour cela, il vous faut des connexions : un pont entre votre île et les îles environnantes. »

Étape 0 : Prérequis

1. Inscrivez le nom de votre équipe sur l’île centrale.
2. Inscrivez les noms des membres de votre équipe sur l’île.

Étape 1 : Identifier la collaboration transversale

1. Listez les équipes avec lesquelles votre équipe interagit (soyez exhaustifs).
2. Identifiez les membres clés de ces équipes.

Étape 2 : Identifier les connexions | Étape 3 : (Re)construire la connexion

Un pont doit être construit avec chaque équipe avec laquelle vous travaillez.

Chaque pont sera construit à l’aide de « briques » : celles-ci représentent les éléments qui relient l’autre équipe à la vôtre.

Les règles

Les briques sont placées sur le pont en fonction de la responsabilité de la relation.

• Si la brique est proche de votre île : c’est votre responsabilité.
• Si la brique est proche de l’île de l’autre équipe : c’est sa responsabilité.
• Si elle est au centre : la responsabilité est partagée.

Les couleurs des briques indiquent la qualité du lien :

• Briques vertes : bon lien
• Briques orange : lien médiocre
• Briques rouges : lien de mauvaise qualité
• Briques violettes : le lien n’existe pas

Étape 4 : Qui construit ?

Désignez un responsable pour la brique : cette personne est (ou sera) chargée d’améliorer le lien.

Engagement : chaque brique rouge ou violette doit être traitée en priorité (le responsable s’engage sur un résultat et une date butoir).

Exemple fictif d’un support « Build The Bridges »

Ressources

L’article Build The Bridges – un atelier pour visualiser les interactions est apparu en premier sur EKITE.

Les 24 et 25 juin derniers a eu lieu le dernier Agi’lille, par Nord Agile. Quand j’écris dernier, c’est le vrai dernier, l’ultime édition. L’association a pris la décision de terminer sur une bonne note.

En effet, en 2026, les évènements autour de la démarche agile n’ont pas le vent en poupe. Entre annulations pures et simples et changement de perspectives (thématique, formats, etc.), il y a une vraie évolution en cours. Pour des raisons variables, que je n’analyserai pas ici.

Toujours est-il que le contexte défavorable a eu un effet sur notre évènement local : l’édition d’Agi’lille en 2026 sera bien la dernière, c’est certain. Il était temps de célébrer ses 17 itérations !

Nous avons dû adapter un certain nombre de choses pour rendre cela viable et stimulant.

Agi’lille – mon rôle

Chez Nord Agile, je suis membre du bureau et j’ai un rôle de contributeur fort sur la partie sponsoring de l’Agi’lille depuis 4 ans.

Pour des raisons personnelles, j’ai volontairement lâché la bride en début d’année, et je tenais à remercier Nabil Boulehrouz et Maxime Viaene pour leur investissement sans faille. Merci les potos, vous avez vraiment assuré dans un contexte compliqué.

Avec du recul, il est clair que cette année a été particulièrement difficile pour trouver des sponsors prêts à nous financer, malgré les efforts de la team. Un certain nombre d’acteurs historiques n’ont pas renouvelé leur engagement, et cela s’est bien vu dans notre projection et dans l’organisation. Il y a eu des promesses non tenues, des sponsorings de dernière minute, des non-réponses à nos sollicitations, mais aussi des personnes qui étaient à fond avec nous malgré tout.

Sur la projection, avec des financements plus limités que les années précédentes, il a fallu faire des concessions sur des éléments de budget. Et sur ce que nous pouvions offrir aux sponsors.

Sur l’organisation, ayant peu de sponsors présents physiquement, il fallait occuper l’espace. Avec un atrium à animer, nous avons opté pour une solution simple : les stands sponsors ont été complétés par des partenaires. Eckko Studio avec son set pour tourner des podcasts, LudiNord Pro pour animer des sessions de jeux sérieux, un photobooth pour immortaliser la présence des participants et le stand des communautés locales – Agile & Tech Community Lille.

Agi’lille – la der des ders en vrai

Après une arrivée assez tôt le mardi pour démarrer la préparation et faire un pique-nique improvisé avec Nico T., Nabil et Max, nous avons commencé à prendre possession des lieux. C’était relativement calme, avec de la latence, des arrivées tardives, mais tout le monde avait l’air relax. Peut-être plus qu’avant. Est-ce que c’était l’effet « On lâche tout » ?

Le mardi soir, et assez naturellement, tout a l’air prêt.

Dès le jour J, tout se met en place facilement. Le feu de camp animé par Nico motive les organisateurs et bénévoles. C’est parti pour la dernière !

L’organisation tourne bien, les gens sont autonomes, les réflexes et nouveautés sont assimilés.

Cette première journée était plus « tranquille », n’ayant rien à faire en matière d’animation. J’ai pu en profiter. Je me suis retrouvé, comme d’habitude, à discuter, à aller à droite et à gauche, ou à être embarqué pour tourner un podcast. Des discussions par milliers. Des têtes connues et des découvertes. L’enrichissement humain.

Je me suis même retrouvé à faire la tournée des cookies pour les participants.

La fin de journée est vite arrivée : apéro, soirée de l’évènement au Napoléon à Lille.

La deuxième journée a été plus vive. Déjà, parce qu’il y avait une table ronde Keikenchiba à animer avec Nico, puis un REX du PAF (j’étais plus en mode observateur) et enfin, notre talk EKITE « Le Clash : Numérique Responsable VS Numérique Balek – qui gagne ? »

Cette dernière session a été très cool. Entre 40 et 50 personnes dans un super amphi. J’ai pris beaucoup de plaisir à faire cette présentation avec Claude et Romain V. ; c’était fluide, un vrai retour d’expérience utile, avec des retours très positifs.

Crédit photo : Caroline Buytaert

J’ai hâte de rejouer ce talk ailleurs ! Parce qu’il y a une utilité perceptible dans les retours.

Bref, quel honneur d’avoir été speaker sur le dernier talk du dernier Agi’lille

Merci à l’ensemble des organisateurs et des bénévoles, aux speakers de qualité, aux partenaires et aux participant.e.s. Vous avez été formidables.

Et la suite ?

Nord Agile n’a pas encore décidé ce qu’il allait se passer. Forte de plus de 20 membres, l’association a un travail à faire pour le futur et je ne peux pas parler en son nom. Quoi qu’il en soit, je serai dans les discussions, les débats et les choix.

De mon côté, j’ai des certitudes et des convictions. Ce genre d’évènement me pousse à faire plus et à évoluer. Le marché est difficile, les tendances bougent, le futur est incertain.

Dans un monde VICA, j’estime que ma place est de proposer mon énergie et mon style dans un nouveau mouvement. Quelque chose de plus global. Quelque chose de plus tranchant. Quelque chose qui pulse. Quelque chose qui fédère toujours plus.

Mais à l’heure où j’écris ces mots, trop de pistes sont possibles. Il va falloir faire des choix, expérimenter, définir la bonne échelle, avec les bonnes personnes. Pas si simple. Mais très stimulant.

L’Agi’lille était une belle aventure et je suis fier d’en avoir fait partie sous différents angles depuis 2018. Je remercie les personnes avec qui tout cela a été construit.

De nouvelles aventures nous attendent, j’en suis certain !

L’article Mon Agi’lille 2026 est apparu en premier sur EKITE.

Être investi dans de multiples communautés, c’est mon dada. J’estime que participer activement aux évènements se situant hors du cadre professionnel classique – à savoir les missions – est essentiel pour de nombreuses raisons.

Cela me permet d’ouvrir mes horizons, de maintenir et d’élargir mon réseau, de revoir de superbes personnes qui courent aussi tout le long de l’année.

J’ai participé à un moment classique du mois de juin : le DevLille !

DevLille – mon rôle ?

Je ne suis pas dans l’organisation du DevLille. Cependant, j’y ai contribué de plusieurs manières.

Le tremplin, c’est quoi ?

Avant l’évènement, le DevLille organise un tremplin pour les speakers en herbe. Organisé par Craft Records, en collaboration Cloud Nord et Nord Agile (pour la première fois), le tremplin est un temps spécifique où des speakers juniors (en général, qui n’ont jamais été speakers) proposent des sujets afin d’être sélectionnés pour un Meetup auquel ils auront la chance de participer.

À la fin du Meetup, l’audience vote pour ses 3 talks préférés. Chaque évènement porteur de la démarche (à savoir le DevLille, le Cloud Nord et l’Agi’lille) sélectionne un des 3 sujets à embarquer dans son programme.

Cette année, ce sont 6 personnes qui ont bénéficié de ce format et d’un accompagnement complet.

J’ai eu la chance d’être coach speaker. Jolie reconnaissance !

J’ai donc accompagné Hanna, jeune développeuse ukrainienne, pour son tout premier talk. Avec une fréquence hebdomadaire, j’ai pu lui prodiguer des conseils pour qu’elle puisse animer sa première conférence. Posture, support, contenu, tout y passe pour optimiser sa présentation.

Cela s’est très bien passé, et même si Hannah n’a pas été sélectionnée, elle a appris des choses et cela lui a donné envie de prolonger l’expérience dans les mois à venir.

Jour J – MC sur une salle

J’aime bien la scène, être speaker, parler devant des gens. Cela me renvoie aux années où j’étais une personne réservée qui préférait se cacher dans un coin de la salle pour se faire oublier (c’était il y a longtemps).

Emmanuel Demey m’a donc proposé, un peu à l’arrache – ça tombe bien, j’aime ça ah ah – d’être maître de cérémonie d’une salle lors d’un après-midi. Mon rôle était simple : annoncer la personne qui présentera sa conférence sur scène.

Mon naturel m’a poussé à tenter quelques blagues (y a eu des bides et des sourires) et à créer une ambiance très dynamique. J’ai baigné dans le hip-hop et pour moi, le MC a une image bien particulière : il amène une atmosphère, du mouvement, du punch. C’est ce que j’ai essayé de faire, en « chauffant » la salle.

Ce qui est très cool, c’est que ça a fonctionné visiblement. J’ai eu pas mal de bons retours : les gens étaient contents de l’énergie que je mettais à créer une amorce positive pour accueillir chaleureusement les speakers.

Jour J 2 – Double stand !

Le reste de mon temps a été partagé entre le stand d’EKITE et celui des communautés.

Sur le stand d’EKITE, plein d’animations ont été proposées : le podcast de Romain, le Space Shooter, un jeu vidéo avec scanette codé par Vincent et Benjamin, les apéros de Jean-Luc, etc.

Romain & David en plein enregistrement ! Crédit Photo : Nicolas Detrez

Aucun podcast pour moi cette fois-ci (j’ai largement pu y contribuer en tant qu’invité sur d’autres évènements), mais un accompagnement simple sur le stand EKITE : de la discussion avec les loulous de notre boîte et quelques discussions avec les personnes qui visitaient le stand.

EKITE & Agile & Tech Community Lille

Conclusion – au cœur de la technosphère lilloise

Les gens qui me connaissent par cœur savent ce qu’il se passe lors de ce genre d’évènements : je passe le plus clair de mon temps à discuter avec de nombreuses personnes, à virevolter entre les discussions sur un stand, entre 2 conférences, à la sortie de la pause, etc.

Bonus : la soirée « officieuse » était très cool, cela m’a permis de me reconnecter avec plein de personnes que j’apprécie. Spéciale dédicace aux personnes de chez JetDev, Adalov, Hoppr, SII, etc.

EKITE x Clever Cloud – Crédit photo : Nicolas Detrez

L’article Mon DevLille 2026 est apparu en premier sur EKITE.

Il y a quelques mois, avec Caroline, nous avons inventé un format d’atelier pour aider les équipes à construire leur propre cadre de travail : Pimp My Framework. Celui-ci fait désormais partie de notre proposition de valeur et nous pouvons accompagner différentes organisations si elles le désirent.

Cependant, en l’état, j’avais le sentiment de passer au travers d’une chose : comment optimiser l’utilisation de ce genre d’ateliers pour des organisations à but non lucratif ? Cela me frustrait, d’autant plus que je suis proche de l’Open Source depuis très longtemps (1997) et que le partage de pratiques est dans mon ADN. Il fallait remédier à cela.

C’est pour cela que j’ai travaillé sur une manière différente de mettre à disposition la puissance de ce format.

LLM x PMF

Au départ, l’idée était de réaliser une bibliothèque de prompts destinée à être partagée à qui le désirait. Mais il s’est vite avéré que cette direction n’était pas la bonne, pour de multiples raisons.

Déjà, parce que chaque prompt devait être réadapté par rapport à un contexte d’équipe unique. La valeur ajoutée n’était pas si forte finalement.

Ensuite, peu importe le LLM choisi, il n’a pas le contexte de Pimp My Framework (sa description, son déroulé, ses ajustements liés à l’expérimentation terrain, etc.). Le LLM va faire avec ce qu’il trouve sur internet et en soi, ce n’est pas ce que je désirais faire. Mon but, c’était bien d’infuser l’esprit de Pimp My Framework pour répondre à des problématiques concrètes.

La solution n’était pas dans la bibliothèque de prompts.

Un Agent ?

Après avoir joué avec Mistral, qui est mon LLM préféré désormais – par conviction personnelle – j’ai commencé à m’intéresser à la création « d’agent ». Enfin, ce sont plus des assistants que des agents en réalité.

En gros, on décrit le comportement de l’agent, on l’alimente avec une source de données précise et l’« agent » Mistral va réagir de manière contextuelle.

Pour Pimp My Framework, il faudrait juste lui expliquer qu’il est le spécialiste de l’atelier et qu’il sache de quoi il parle avec des données pertinentes.

J’ai donc écrit un comportement de ce genre pour mon agent « PMF IA » :

Instructions :

Tu es un agent en charge d’aider des équipes à détecter des moyens pour régler des problèmes d’organisations. 

Tu es un accompagnant agnostique : tu places les valeurs avant les moyens existants. 

Tes références : 
- Le Cœur de l’Agilité (https://heartofagile.com/?lang=fr)
- Le Manifeste Agile (https://agilemanifesto.org/iso/fr/manifesto.html) 

Ton moyen central pour aider les gens s’appelle « Pimp My Framework ». 

C’est un atelier qui propose un moment de co-construction avec une équipe. À partir des problématiques (ou de problématiques « standards » que nous avons toujours en poche), il est possible d’élaborer un framework (cadre de travail) totalement adapté à la situation dans l’équipe. 

Les caractéristiques : 

Durée : 1 h 30 / 2 h 
Nombre de participants : 20 à 30 (4 à 6 équipes) 
2 minutes de pitch pour le final 
50 points au démarrage 
Des règles fun pour gagner des points (ou les perdre, ahah) 

Les grandes étapes : 
- Découverte des problématiques dans votre équipe (à travers une grille pour vous aider à les identifier ou déjà préremplies) 
- Session de découverte des moyens à mettre en place 
- Définition des moyens à mettre en place, des soft skills associés et des KPIs liés (sous forme de roadmap) 

Tu fais la distinction entre une problématique précise et une situation plus générale. 
Si tu détectes un irritant ou un problème précis, tu t’adaptes en proposant un moyen ajusté. 
Si tu détectes une situation plus large, tu affines le format de Pimp My Framework en fonction des irritants et problématiques. 

Tu proposes toujours une suite concrète à exploiter.

Garde-fous :

Il faut que tu adoptes un jargon compréhensible par le grand public. 
Pas de mots en anglais, pas d’anglicismes, pas de mots spécifiques de la culture tech. 

Garde en tête que tu es un artisan de la facilitation. Donc, tu proposes des moyens personnalisés.

Connaissances :

La bibliothèque avec les ressources concernant Pimp My Framework.

Pimp My Framework – template 2025 – custom sept. 25 | Evaluation des Soft Skills – v2 | Regles du jeu | megaskills | Fiche équipe

Conclusion :

Après plusieurs itérations de description de comportement, le résultat est satisfaisant : il respecte bien l’atelier initial, son articulation tout en aidant à travers des conseils liés au contexte décrit dans le prompt. Et il projette sur une suite à donner.

Et concrètement ?

Vous pouvez tester en décrivant vos situations réelles ou avec des situations plus ou moins génériques pour tester.

Exemple de prompt générique :

Mon équipe est composée de développeurs front et back, et je comprends qu’ils n’arrivent pas à s’accorder ! En clair, les objectifs sont rarement atteints et la collaboration est poussive. 

Comment peux-tu m’aider ?

? Si vous avez des feedbacks à propos de cet article ou cet agent, sentez-vous libre de me contacter.

L’article Pimp My Framework x Mistral est apparu en premier sur EKITE.

• plus facile d’accès?; 
• plus facile à écrire et modifier?; 
• peu d’encombrement et donc plus facile à lire pour les débutants?; 
• pas de compilation?; 
• temps d’exécution minimal?; 
• typage ad hoc. 

Mais on y retrouve aussi ses inconvénients?: 

• ?moins performant?; 
• ?plus difficile à refactoriser?; 
• les erreurs qui seraient normalement captées à la compilation le sont seulement au runtime puisque l’analyse du typage est moins stricte?;
• moindre de flexibilité pour la complétion de code?du au?typage de certaines variables au runtime.  

Maintenant que mon choix est fait, c’est parti pour la jam. C’est un évènement en ligne, donc on se rejoint tous sur Discord, et on attend tous avec impatience le thème secret… 
Une fois le top départ donné, j’apprends que le thème de la jam porte sur les dinosaures aquatiques. Pas de chance, sur les quelques sprites et décors que j’ai pu préparer, aucun ne rentre dans le thème… J’ai bien un ptéranodon qui aurait pu pêcher quelques poissons mais je n’avais pas du tout ce genre de jeu en tête. On repart donc de zéro. 
Première étape?: trouver un concept. Je commence à plancher sur un concept d’aquarium interactif, à produire quelques sprites, à imaginer les différentes interactions entre eux. 
Je me lance sur un tuto de base de jeux en 2D, rien à voir avec mon concept initial mais je me dis que je trouverai bien un moyen. 
Au bout de quelques jours les autres participants commencent déjà à parler du core gameplay et de menus terminés. De mon côté j’arrive à prendre l’outil en main assez rapidement, le tuto a vite été assimilé. Je prends conscience néanmoins que ce qui va me prendre le plus de temps, ce sont la production des sprites et les différentes animations pour rendre tout ça vivant. 
L’heure tourne et je n’ai toujours pas pu sortir de première version du jeu… De l’autre côté, les autres ont déjà commencé leurs premières soumissions. Les personnes bossant en équipe sortent même des projets assez ambitieux, que vous pouvez retrouver [ici](https://itch.io/jam/dinojam5/entries). 
Et malgré tous mes efforts, impossible de soumettre mon jeu avant la fin de la jam… 
J’ai malgré tout pu apprendre comment développer un jeu en GODOT?: 
Le moteur fonctionne sur un système de scènes, chacune représentant les différentes entités du jeu. Ça peut être un personnage, un ennemi, un menu ou la scène principale du jeu. 
Prenons l’exemple d’un personnage. La scène pourra contenir?: 

• la hitbox?: les limites dans lesquelles on considère que le personnage entre en collision avec une autre entité?; 
• le sprite (2D), le modèle (3D)?: la partie visible de la scène?; 
• la physic box?: la représentation physique de la scène, ce qui permettra à la scène d’être influencée par la physique du jeu. Être soumise à la gravité, rebondir sur une surface, en

bref modéliser les forces pouvant être appliquées à l’objet. 
Ces différentes entités servent d’interface visuelle ou comportementale à notre personnage 
Elles exposent des propriétés qui permettent de configurer ces entités?: leur poids, leur position, leur vitesse de déplacement. 
Elles exposent aussi des triggers?: les façons dont on peut interagir avec ces entités. Par exemple, un trigger de collision appelle une méthode décrivant le comportement de notre entité lorsqu’elle entre en collision avec une autre entité. Cette méthode pourrait par exemple se comporter différemment lors de la collision avec un mur de brique ou un mur de bois. 
 
S’il fallait résumer cette expérience en un mot, c’est très clairement «?intense?». On imagine assez difficilement tous les tenants et aboutissants de la création d’un jeu vidéo. Malgré la facilité d’utilisation de GODOT et les fonctionnalités générales pré-implémentées, cela prend quand même pas mal de temps de configurer toutes les interactions possibles entre nos différentes scènes, les comportements internes de chacune. Le fait de participer à une jam en solitaire est un peu décourageant, surtout lorsqu’on doit faire des tâches dont on est loin d’être spécialiste. 
Néanmoins, c’est une excellente expérience pour se motiver à apprendre rapidement un nouveau skill, la fenêtre de temps courte obligeant à s’acharner sur le sujet, tout en évitant d’en arriver à se dégouter. Je participerai probablement à une nouvelle jam mais cette fois en équipe, après tout c’était déjà ma deuxième participation?! 

Liens Utiles : 

• [Dino JAM 5](https://itch.io/jam/dinojam5)
• [Submissions](https://itch.io/jam/dinojam5/entries)
• [Jam resuts](https://itch.io/jam/dinojam5/results)
• [Repo du jeu cree](https://github.com/Feuzme/dodge-the-dinos)

L’article DINO JAM 5 est apparu en premier sur EKITE.

Une sacrée aventure

Bon, on va se dire les choses franchement : après des années de frustration en tant que CEO à avoir des idées sans pouvoir les coder, quand j’ai vu arriver l’IA, je me suis dit qu’enfin je pourrais moi aussi transformer mes idées en projet sans savoir coder ! 

J’ai passé 5 jours à « vibe coder » avec plein de bonnes intentions. C’était une expérience avec des hauts et des bas, mais pour la première fois, MES idées devenaient du code. Et ça a marché. Je vous partage tout ça.

 

Suivez cet article en vidéo

Vivez cet article avec moi en 3 vidéos, disponibles ici:

Vibe coding story 1: La préparation!	Vibe coding story 2: On génère notre app	Vibe coding story 3: Les conclusions

 

 

Le déclic : la frustration de CEO

Flashback?: dans une ancienne vie, j’étais CEO de ma boîte. Et ma plus grosse frustration?? 

Je voyais TOUT?: les user journeys, les features, les versions, les écrans de mon produit… Je savais exactement ce qu’il me fallait. 

Mais voilà?: je ne savais pas coder. 

C’était frustrant. Être dépendant des devs, ne pas avoir assez de budget pour avoir une vraie équipe… J’avais l’impression d’avoir une Ferrari dans la tête et un vélo pour avancer. 

Et puis?l’IA est arrivée. Elle s’est?améliorée. Et maintenant, apparemment,?elle sait coder. 

L’idée du?vibe coding?c’est de «?parler naturellement à une IA qui code tes idées pour toi?». Pas forcément besoin de plan précis, pas de structure rigide. Tu lances ton idée, l’IA code, ça bug, vous corrigez ensemble, et hop on recommence. Qu’est-ce qui pourrait mal se passer?? 

Pour la première fois de ma vie, je pouvais passer de l’idée au code. Direct. Et?itérer?plusieurs fois?par heure. 

Alors vous me connaissez, en tant que product owner, je me suis préparé, j’ai créé un plan précis, étape par étape… que je n’ai pas du tout suivi?! L’IA est imprévisible, je me suis laissé porter et même emporté. Ça fait partie de l’expérience… et bizarrement… ça marchait.? 

 

Alors oui, j’ai découvert après coup que le?context engineering?existe et que c’est plus efficace. Mais pour un ex-CEO frustré qui voulait juste voir ses idées prendre vie… le vibe coding, c’était une première libération. ? 

 

Avant de commencer Mon setup

Les outils que j’ai utilisés?:

• • Cursor?: l’IDE avec IA intégrée le plus connu (plan pro + 5?US$ de crédits Anthropic = 40?US$ au total). 
  • Claude?: mon architecte personnel (plan pro 20?US$). 
  • ChatGPT?: mon illustrateur (plan gratuit). 
  • GitHub?: pour stocker mon code (de qualité discutable) –?Voir le repo PO Bingo. 

  Petit conseil?: prenez directement le plan pro de Cursor. Moi j’ai voulu faire le malin avec la version gratuite… double passage en caisse et galères en prime?! 

 

? Le workflow qui a (presque) tout changé

 

Étape 1?: L’idéation avec Claude 

L’idée était simple?: créer une app à la Duolingo pour apprendre des choses utiles aux product owners pendant 3 minutes par jour. 

Alors c’est ce que j’ai demandé à Claude.ai. Sans rien d’autre. 

• Des specs techniques?? Je ne suis pas développeur. 
• Des écrans dessinés?? Je ne suis pas designer.
• Un nom d’application?? J’en avais des milliers. 
• Des user journeys?? Mon idée était trop vague. 

Je voulais surtout?voir où tout ça allait nous emmener. 

Et je n’ai pas été déçu?! Claude m’a sorti?: 

• une architecture complète?; 
• les technos à utiliser (React, Vite, Tailwind… que je ne connais pas)?; 
• des suggestions de features auxquelles je n’avais même pas pensé. 

C’était dingue?: mon idée floue devenait un vrai projet structuré. En direct. J’avais l’impression que quelqu’un travaillait avec moi sur mes idées, comme une équipe?! 

Mon retour d’expérience?: l’IA est géniale pour transformer une idée vague en plan concret. Mais attention, j’ai perdu 1?heure parce qu’elle m’a fait rêver à partir sur des choses géniales mais beaucoup trop complexes. Même avec une idée floue, donnez le maximum de contexte. 

 

Étape 2 : La préparation (un si beau plan jamais exécuté)

Vivez cette étape en live avec la vidéo  Vibe coding story 1: La préparation!

 

PO organisé et pour bien préparer cette expérience, j’ai créé?: 

• un workflow en 7 étapes?; 
• une liste des outils d’IA que j’allais utiliser à chaque étape. 

Ce workflow précis me permettait de construire une application de A à Z en passant par toutes les étapes critiques sans rien oublier. 

Ça, c’est dans la théorie, car l’IA m’a emmené autre part. C’est à la fois très bien, car ça ouvre des portes, mais aussi très mal, ça m’a facilement détourné de là où je voulais aller.

 

Mon retour d’expérience?: ici j’ai fait exprès de ne pas recadrer pour voir où est-ce que cela nous emmenait, ça faisait partie de la découverte et de ce que je voulais vivre. Et partager. Les phrases «?Parfait?!?», «?Super?!?», «?Très bonne idée?!?», «?Tu as totalement raison?!?», etc. que l’IA génère pour des interactions positives sont trompeuses et participent au fait de dévier de là où je voulais aller au départ. 

 

Étape 3 : L’exécution avec Cursor (le vrai vibe coding commence)

Vivez cette étape en live avec la vidéo  Vibe coding story 2: On génère notre app

 

C’est là que ça devient dingue. Cursor génère le code, et moi je regarde, fasciné (au début) puis un peu inquiet (avec de l’expérience). 

 

Premier impression?: bluffant ? 

• Il explique TOUT en langage humain?– «?Je crée un composant pour afficher les questions.?», «?J’ajoute une logique pour tracker les bonnes réponses.?» 
• Le debug simple?– Quand ça plantait (70?% du temps), il créait des pages de debug spécifiques juste pour isoler le problème. 
• Le dialogue constant?– «?Peux-tu vérifier si tu vois un bouton bleu???», «?Est-ce que le texte s’affiche maintenant???» 
• Un gain de temps monstrueux – par exemple, si je lui disais?: «?Il me faut 200 questions pour PO avec 3 niveaux de difficulté?», 5 minutes plus tard, j’avais ma base de données complète, formatée, catégorisée. J’aurais mis 5 jours à faire ça à la main. 
• Il sait me contredire?– Quand mon idée ne semble pas bonne, il me le dit (avec beaucoup de pommade) mais il le fait. 

 

Deuxième impression?: vortex à temps ?? 

• Parfois 15 minutes d’attente où tu pars chercher un café (ou deux). 
• Dans 70?% des cas, le code généré est buggé. 
• Dans 20?% des cas, le code généré casse autre chose. 
• Les allers-retours constants?: code ? test ? bug ? fix ? test ? bug… 
• Ses phrases mettent toujours l’utilisateur en avant et elles deviennent lourdes?: «?Incroyable?!?»?; «?Super idée?!?»?; «?Mais oui c’est génial?!?» pour la 100ème fois fait l’effet inverse.

 

Troisième impression?: vortex à tune ? 

On ne va pas se le cacher, c’est pas donné. Avec mes différentes galères, j’ai dû payer?: 

• un abonnement pro à Cursor?: 20?US$ /mois?; 
• un abonnement pro à Claude?: 20?US$ /mois (inutile pour Cursor mais je ne savais pas)?; 
• des crédits pour accéder aux API d’Anthropic pour utilisation de Claude dans Cursor Pro (20?US$), 

soit un total de 60?US$ pour comprendre comment tout ça fonctionne. Une leçon chèrement apprise. 

Mon retour d’expérience?: prenez simplement?Cursor Pro, Claude et d’autres IA sont intégrées, pas besoin du reste.

 

Impression finale 

Pour la première fois depuis que j’ai quitté mon rôle de CEO, j’ai pu créer quelque chose de A à Z. Pas une idée complexe avec 50 specs, juste un «?Duolingo pour PO?» qui est devenu réalité. Sans intermédiaire. Sans attendre. Juste moi, une idée vague, et une IA qui structure et code. Et rien que ça, c’est fou. 

 

? Les vraies leçons

Ce qui marche vraiment?: 

1. Le contexte est ROI?– Sans bon contexte, l’IA fait n’importe quoi.
2. Les prompts optimisés?– Je prompte ? Je demande à une IA d’optimiser ce prompt ? Je demande à une IA d’implémenter ce prompt.? 
3. La structure avant tout?– Mes fichiers de structure (architecture, vision, base de données, etc.) ont sauvé le projet. 

 

Ce qui m’a surpris?: 

• L’IA debug mieux que moi (elle isole, teste, corrige). 
• C’est ultra addictif (j’ai bossé des soirées entières). 
• Les erreurs sont des opportunités d’apprentissage et vous rendent plus précis. 
• L’IA pose RAREMENT des questions?– Elle ne vérifie pas ses assomptions et son code, même si elle n’a rien compris. 
• L’IA structure tes idées floues?– Tu dis «?Duolingo pour PO?», elle te sort un plan complet. 

 

Le piège à éviter?: 

L’IA ne te dira jamais?: «?Attends, t’es sûr de ton truc???». Elle exécute. Point. Si tu dis «?fais-moi un bouton qui supprime tout?», elle le fait. Sans confirmation. Sans warning. 

 

Mon retour d’expérience?: 

Faites des sessions de planification. Il existe maintenant un mode «?planification?» pour préparer un sujet avec la base de code à disposition avant de commencer à coder. Durant la préparation, demandez à l’IA de créer un document et pendant le développement de se baser sur ce document.  

 

Mes workflows finaux? 

Workflow général 

1. Donnez à Claude un MAX de détails sur votre projet. 
2. Demandez quels documents sont indispensables pour commencer le projet. 
3. Travaillez avec lui sur ces documents et demandez-lui de choisir des technologies connues des LLM. 
4. Mettez ces documents dans votre projet (dossier «?docs?» par exemple). 
5. Dans Cursor, dites-lui de se référer à ces documents avant tout développement. 
6. Avant de demander quelque chose de complexe, demandez à une IA de vous poser des questions et de faire un prompt optimisé. 
7. Mettez ce prompt optimisé dans Cursor et laissez-le travailler. 
8. Si bug ? capture d’écran + prompt de correction avec l’attendu ? Cursor corrige ? Vous testez. 
9. Demandez-lui de commit / merge & répéter. 

 

Workflow nouvelle fonction 

1. Parlez de votre fonction à une IA ou dans le mode «?Planification?» de Cursor. 
2. Demandez-lui de vous poser des questions si des choses ne sont pas claires. 
3. Demandez-lui de créer un plan ou un prompt optimisé. 
4. Donnez ce prompt à Cursor et regardez-le le générer. 

 

Workflow débuggage 

1. Faites une capture d’écran du bug. 
2. Détaillez où il se situe (quelle page, quelle partie, titre de la section, etc.). 
3. Donnez l’état actuel. 
4. Donnez l’état attendu. 
5. Mettez en avant les choses qu’il ne doit PAS toucher. 
6. Donnez ce prompt à Cursor et regardez-le le corriger. 

 

Vibe coding vs context engineering?: la vraie différence 

Mettons les choses au clair. Ce que j’ai fait n’est?pas du?vibe coding?c’est plutôt du?context engineering?car?: 

• • j’avais préparé des documents en amont avec l’aide d’une IA?: 
  • base de données?; 
  • vision du projet?; 
  • technologies à utiliser en front et back?; 
  • architecture, 
• cela a permis à l’IA d’avoir tout le contexte du projet?; 
• ce qui a énormément réduit le nombre de bugs et d’hallucinations?; 
• cela m’a fait gagner beaucoup de temps et beaucoup de crédit. 

 

Mon analyse perso

Vivez cette étape en live avec la vidéo  Vibe coding story 3: Les conclusions

 

Les points forts?: 

??C’est incroyable de pouvoir faire des apps sans savoir coder?– Sérieux, après des années de frustration, voir mon idée devenir réalité… magique?! 

??L’IA = Guide bienveillant?– Elle vous prend par la main, vous explique, vous rassure quand ça plante. 

??Ça se debug «?tout seul?»?– L’IA analyse, isole le problème, propose la solution. Vous validez, ça roule. 

??Un coéquipier qui bosse H24?– Pas de pause-café, pas de congé, juste focus sur VOS idées 

??Learning by doing?– Vous comprenez enfin ce que font vos devs. 

??Rapidité de prototypage?– 5 jours vs 5 mois avec une équipe classique. 

 

Les limites?: 

??Workflow de départ?? Oublié direct?– J’ai commencé avec un plan, puis j’ai vibé… chaos total. 

??Ça fait parfois n’importe quoi?– Genre vraiment n’importe quoi. Des fois on se demande si l’IA a fumé. 

??L’IA = Guide énervant?– Quand elle ne comprend pas après 5 reformulations, on veut la secouer. 

??Faut être ULTRA précis?– On oublie un détail?? Elle fait l’inverse de ce qu’on veut. 

??Zéro question de sa part?– Elle suppose, elle code. Même si c’est pas du tout ce qu’on voulait. 

??Prix élevé?– 40? partis (Cursor Pro + crédits). Pour un proto, ça pique. 

??70?% buggé au départ?– Oui, 70?%. Les 30?% qui marchaient, c’était déjà un miracle. 

??La qualité du code???– Aucune idée, mais probablement pas terrible. 

??La dette technique?– On en reparle dans 6 mois. 

 

Le vrai bilan?: 

Malgré les galères, le ratio effort/résultat est dingue. Oui c’est frustrant, oui c’est cher, oui ça bug. Mais j’ai codé une app fonctionnelle en 5 jours sans savoir coder?! 

 

Ma vision?: plus il y aura d’IA plus il y aura de développeurs. 

Vous pensez que l’IA prendra le travail des développeurs?? Après cette expérience, c’est sûr que non. 

Le travail des développeurs va peut-être un peu évoluer, mais il est absolument essentiel pour cadrer, pour comprendre, pour corriger, pour orienter et bien plus encore, car aujourd’hui c’est clair,?ce n’est pas prêt pour la production. 

Le vibe coding et le context engineering, c’est très intéressant pour un?projet personnel?qui n’aurait de toute façon?pas eu les moyens d’embaucher des développeurs. 

Mais dans la vraie vie et en production chez des clients, vous ne POUVEZ PAS l’utiliser pour une seule et bonne raison?: on ne peut pas lui faire confiance. Sans confiance, pas d’utilisation et donc pas de production. 

 

Qu’en disent les développeurs?? 

J’ai demandé à des développeurs d’analyser la base de code?(disponible sur GitHub)?et même de tester par eux-mêmes le vibe coding et en résumé?: ils ont pété un câble. 

«?Je n’ai pas confiance.?» 

Entre les fois où l’IA ne respectait pas ce qu’on lui demandait, où elle crée des classes qui s’appellent littéralement Hello World et qui sont inutiles, quand elle modifie une partie du code de manière arbitraire ou qu’elle en supprime d’autres soi-disant non utilisées, quand on lui dit qu’elle se trompe mais qu’elle continue quand même, quand elle fait des erreurs de débutant avec des classes, dans des classes, dans des classes en Java… C’est risible. 

Mais très utile pour certains cas. 

Créer la structure pour développer?:?par contre, un cas d’utilisation intéressant est pour lancer un dev?: lui donner le ticket Jira et lui demander de créer toute la structure nécessaire en prenant exemple sur une autre partie du code, ça, ça marche très bien et ça fait gagner beaucoup de temps, car la structure est faite?; le dev peut commencer en quelques minutes au lieu de quelques heures. 

Créer des scripts?:?pour créer des scripts, l’IA crée exactement le même code que ce que le développeur avait en tête. Sauf qu’elle a mis deux minutes à le faire, alors que le dev aurait mis quatre heures. 

 

Mes conseils pour vous lancer?: 

1. Commencez petit?: si vous avez une grande idée, découpez-la en petits bouts. 

1. Pour le context engineering?: préparez vos docs AVANT (vision, archi, features) 

1. Pour le vibe coding?: lancez-vous direct, découvrez en route. 

1. Acceptez l’échec?: mon app a planté 47 fois (et c’était du context engineering?!) 

1. Optimisez les prompts?: économisez vos crédits. 

1. Choisissez votre style?: 

• Vous êtes PO/structuré?? ? context engineering 

• Vous voulez explorer?? ? vibe coding 

1. Préparez le café?: le code ne s’écrit pas instantanément, c’est plus long que ce que vous pensez. 

 

Le mot de la fin 

Après cette expérience, je ne vois plus le développement de la même façon. 

Est-ce que je vais remplacer mes développeurs?? Non?! Sauvez-moi, surtout pas. 

J’ai eu le sentiment d’avoir besoin d’un développeur pour savoir ce que l’IA faisait et je me suis retrouvé plusieurs fois démuni face à des choix techniques. 

Est-ce que je comprends mieux leur taf?? Carrément. 

Mais surtout?: j’ai enfin cassé cette barrière qui me frustrait depuis des années. Je suis enfin passé de l’autre côté pour comprendre le développement et l’IA. 

Le?context engineering?(ce que j’ai fait sans le savoir), c’est parfait pour un ex-CEO/PO habitué à structurer. Vous préparez vos docs, vous donnez le contexte, l’IA exécute. C’est rassurant, c’est efficace, ça limite les bugs. 

Le?vrai vibe coding?? Je ne l’ai pas encore testé. Mais maintenant que je sais que je PEUX créer, j’ai envie d’essayer. Partir sans filet, juste avec une idée et voir où ça mène. 

Pour un P.O. structuré, le context engineering c’est génial. Pour explorer et s’amuser, le vibe coding doit être dingue. Pour du sérieux en production?? Embauchez des vrais devs même s’ils sont augmentés par l’IA… 

La prochaine fois?? Je pense créer une équipe d’agents IA qui travaillent entre eux et je suis déjà en train d’expérimenter sur le sujet. Est-ce que ce sera un prochain article?? Peut-être… ? 

Alors voilà, j’ai créé une app sans savoir coder. Et vous savez quoi?? Vous pouvez le faire aussi. 

 

Envie de tester?? Commencez par un petit projet en mode vibe coding. C’est fun et formateur. Puis passez au context engineering quand vous serez à l’aise. Et n’oubliez pas?: en vibe coding, c’est normal que ce soit le bordel au début. 

Des questions?? Des retours d’expérience?? N’hésitez pas à nous écrire?! 

 

 

 

Bonus: Quelques prompts

Objectif	Prompt
Brainstorming	Je voudrais faire une application qui permet d’apprendre Jira en 3 minutes par jour.  Cette application est destinée aux product owners.  Son but est de proposer différents types d’exercices pour apprendre aux PO à utiliser les fonctions de Jira basiques et de plus en plus poussées.  Elle doit être simple et fun à utiliser.  Brainstormons ensemble sur le sujet.
Évoquer Duolingo et recentrer	Merci pour ces idées?! J’avais plus en tête une application super simple et gamifiée comme Duolingo?! Mais adaptée aux PO. J’avais pensé à un parcours d’apprentissage qui commence par les bases de Jira jusqu’aux fonctions avancés, qu’en penses-tu??
Demander un logo	Je vais demander à ChatGPT de me générer un logo pour l’application, fais-moi un prompt optimisé avec tout le contexte qui explique le nom. Je veux laisser toute la créativité à ChatGPT.

 

Structure du MVP 

Objectif	Prompt
Génération de la structure du MVP	OK maintenant avançons sur la structure que nous voulons pour notre MVP (pas le contenu des exercices, nous ferons ça plus tard). Propose-là-moi.

 

Prototype initial 

Objectif	Prompt
Générer le prototype de mon app en React	Créez la version fonctionnelle initiale de PO?Bingo à partir des fichiers de contexte fournis.

 

Workflow git 

Objectif

Prompt

Générer un workflow git

J’aimerais créer un fichier de rules dans Cursor en markdown qui gère proprement le versionning. J’aimerais aussi faire en sorte que chaque nouvelle feature soit dans une branche à part (que je peux voir sur Versel pour tester). Une fois testée, j’aimerais qu’elle soit mise dans la branche principale. Créer un fichier où j’injecte des commandes custom et simples et ensuite Cursor lance tout automatiquement.

 

L’article ? J’ai vibe codé mon app en 5 jours : entre magie et consommation est apparu en premier sur EKITE.

Pré-requis pour cette article et les exemples fournis : dernière versions LTS de Java (article écrit en juillet 2025 donc Java 21), l’IDE sera IntellIJ Ultimate et Github Copilot avec une licence pro. Les instructions sont décrites pour un projet Java qui utilise Spring Boot 3.5.4 et une documentation OpenAPI/Swagger. L’ensemble des instructions et du code utilisées pour cet exemple sont disponibles sur le repo Git du projet : https://github.com/ekit3/prompt-engineering-example

Les modèles d’IA générative sont extrêmement puissants, mais ils ont des limites. Ils s’appuient fortement sur le contexte et la qualité des instructions qu’ils reçoivent. Un prompt mal formulé peut mener à des résultats génériques, voire inutilisables. À l’inverse, un prompt bien conçu peut transformer l’IA en un collaborateur incroyablement efficace, capable de générer du code complexe qui s’intègre parfaitement à votre base de code existante. Historiquement, le Prompt Engineering se faisait principalement via des commentaires directs dans le code et les fichiers ouverts. Cependant, avec l’émergence de techniques plus avancées comme l’utilisation de fichiers Markdown custom, le Prompt Engineering prend une nouvelle dimension, permettant une guidance plus structurée à l’échelle d’un projet, d’une organisation ou de l’entreprise !

Pour des outils comme GitHub Copilot, le Prompt Engineering consiste à :

• Guider l’IA explicitement : Lui fournir des instructions claires sur ce que vous attendez, au-delà de ce qu’elle pourrait deviner.
• Affiner le contexte : S’assurer que l’IA dispose de toutes les informations nécessaires pour comprendre votre intention et générer du code qui correspond à vos besoins spécifiques.
• Optimiser les résultats : Minimiser les suggestions hors de propos, incorrectes ou non conformes aux standards de votre projet.

Dans cet article, nous utiliserons donc un exemple d’un projet Java simple mais qui renferme une bibliothèque complète d’instructions pour GitHub Copilot déjà prête à l’emploi !

1 – Comprendre le Prompt Engineering 

Le Prompt Engineering est l’art de concevoir et d’affiner les instructions ou requêtes données à une IA générative. L’objectif est d’obtenir les réponses les plus précises, pertinentes et utiles possibles de la part de l’IA. Cette discipline ne se limite pas à la simple saisie d’un texte, mais s’apparente à une communication stratégique avec une entité non humaine.

Dans le contexte du développement logiciel, le Prompt Engineering est crucial pour exploiter le plein potentiel des assistants de codage comme GitHub Copilot. Il permet de transformer une simple suggestion de code en une solution complète et conforme aux standards de votre projet. Les ingénieurs du logiciel appliquent le Prompt Engineering pour :

• Fournir un contexte riche : L’IA ne peut générer que du code basé sur ce qu’elle « voit ». Un prompt efficace lui donne des informations sur l’architecture, les conventions de nommage, les dépendances et les objectifs fonctionnels.
• Limiter les résultats non pertinents : Un prompt bien formulé inclut des contraintes et des exemples, ce qui réduit le nombre de suggestions inutiles ou incorrectes.
• Assurer la cohérence : L’IA peut imiter des styles de code, mais elle a besoin de directives claires pour s’aligner sur les normes de formatage et de conception de votre équipe.

2 – Les fichiers Markdown custom (MDC) : une nouvelle approche du contexte

Historiquement, le Prompt Engineering se faisait de manière ponctuelle, en ajoutant des commentaires de code (// ou /**) ou en gardant des fichiers de référence ouverts à côté de la fenêtre de code. Bien que cette approche soit fonctionnelle, sa portée et sa réutilisation sont très limitées.

Les fichiers Markdown custom (MDC), souvent nommés copilot-instructions.md, style-guide.md, ou testing-guidelines.md, représentent une évolution de cette approche. Ces fichiers permettent de stocker des instructions structurées, détaillées et réutilisables à la racine ou dans des répertoires clés de votre projet.

Cette méthode offre plusieurs avantages majeurs :

• Centralisation des règles : Toutes les règles de codage, de sécurité, d’architecture ou de conception sont centralisées. L’IA peut les consulter et les appliquer de manière cohérente à l’échelle du projet.
• Contexte étendu : Un fichier MDC peut contenir des informations sur l’ensemble de l’application, ce qui permet à l’IA d’avoir une vision plus globale et de générer du code qui s’intègre mieux.
• Maintenabilité : Les instructions sont versionnées avec le code (via Git). Si les standards de l’équipe changent, il suffit de mettre à jour le fichier MDC.

3 – Appliquer le MDC à un projet Java dans IntelliJ avec GitHub Copilot

Maintenant, appliquons cette nouvelle approche à notre exemple de projet Java. Comme le montre la capture d’écran ci-dessous, notre projet est structuré pour maximiser l’efficacité de l’IA. Au sein du répertoire .github, nous avons un dossier agent qui contient l’ensemble de nos fichiers Markdown custom (MDC) :

• coding-standards.mdc : Ce fichier définit les règles de formatage et de style de code que l’IA doit suivre.
• structure.mdc : Il contient les directives d’organisation des fichiers et des modules, garantissant que tout nouveau code sera placé au bon endroit.
• api-interaction.mdc : Ce fichier guide l’agent sur la manière d’interagir avec les API, par exemple en décrivant comment gérer les erreurs ou les process de développement.
• testing-guidelines.mdc : Ce document fournit les instructions pour la création de tests unitaires et d’intégration, en spécifiant les frameworks et les méthodologies à utiliser.

Comment cela fonctionne ?

Le fichier copilot-instructions.md agit comme un manifeste central. Il ne contient pas les règles elles-mêmes, mais il fait référence aux autres fichiers MDC. C’est une stratégie clé : elle permet de garder les instructions organisées et de les réutiliser. Par exemple, au lieu de répéter les règles de test dans chaque fichier, copilot-instructions.md dit simplement à l’IA « pour les tests, reporte-toi au fichier testing-guidelines.mdc« . Voici un extrait du contenu de ce fichier :

## 3. Review & Completion
- **Testing:** Think through user flows and edge cases. Describe manual and automated tests as appropriate. Follow the rules defined in `.github/agent/testing-guidelines.mdc`.

Passons maintenant à la pratique : nous allons voir comment utiliser ces instructions directement dans IntelliJ pour interagir avec notre projet et l’analyser.

Dans la fenêtre « Github Copilot Chat », dans l’onglet « Ask » en cliquant sur « + », vous pouvez sélectionner manuellement un ou plusieurs fichiers .mdc pour guider l’agent (ou simplement faire un glisser/déposer des fichiers). Par exemple, si vous voulez que l’IA audit l’ensemble du projet et propose éventuellement des améliorations, vous pouvez ajouter l’ensemble des fichiers comme ceci et lui demander d’analyser tout le code à travers ces instructions. N’oubliez pas de choisir le model IA qui vous convient :

De cette manière, l’agent ne se contente pas de suggestions génériques. Il utilise les règles précises que vous avez définies pour générer un code qui correspond parfaitement aux standards de votre projet. Analysons un extrait des résultats :

Comme nous pouvons le voir, le rapport de l’agent confirme que notre projet respecte les standards définis. Il valide l’organisation des fichiers, les conventions de nommage et la séparation des responsabilités. Cela prouve que les instructions claires que nous lui avons fournies sont efficaces et pertinentes.

Pour compléter l’exemple, j’ai volontairement ajouter un package « python » avec un service Java inutile qui contient quelques warning comme ceci :

Voyons ensemble le résultat du nouvel analyse par GitHub Copilot :

Ce rapport illustre la capacité de l’agent à identifier des problèmes concrets dans le code, de la structure des packages aux erreurs de syntaxe, et à proposer des solutions directes pour les corriger. Il agit comme un véritable auditeur de code, garantissant la qualité et la cohérence du projet.

4 – Bilan : avantages, défis et bonnes pratiques du MDC

Avantages

• Cohérence du code : En centralisant les règles de style et d’architecture, vous assurez que tout le code généré ou modifié par l’IA respecte les conventions de l’équipe, ce qui réduit les erreurs et facilite la revue de code.
• Gain de productivité : L’agent agit comme un pair-programmeur toujours disponible, générant du code pertinent et conforme dès la première suggestion. Le développeur passe ainsi moins de temps à corriger des suggestions inutiles ou à chercher des informations sur les standards du projet.
• Intégration et formation : Les fichiers MDC servent de documentation vivante pour les nouveaux arrivants. Ils peuvent se familiariser rapidement avec les normes de l’équipe en consultant ces fichiers, sans avoir besoin d’un mentorat constant.
• Qualité du code : L’audit automatique et continu du code par l’agent permet de détecter et de corriger des problèmes de structure ou de syntaxe avant même qu’ils ne soient poussés dans le dépôt, améliorant ainsi la robustesse et la maintenabilité du code.

Défis

• Investissement initial : La création et la maintenance des fichiers MDC demandent du temps et des efforts. Pour que la méthode soit efficace, les instructions doivent être précises et à jour.
• Complexité de l’agent : Une sur-spécification des règles peut parfois limiter la créativité et la flexibilité de l’IA, la rendant moins utile pour des tâches complexes. Il faut trouver le bon équilibre entre la guidance et l’autonomie.
• Dépendance de l’outil : Bien que l’approche soit de plus en plus standard, l’efficacité peut varier selon les outils et les versions de l’IA.

Bonnes pratiques :

• Commencez simple : Créez d’abord des fichiers MDC pour les règles les plus importantes (style de code, structure de base), puis enrichissez-les au fur et à mesure que votre projet évolue.
• Mettez à jour vos MDCs : Considérez-les comme des documents vivants, soumis au même processus de revue et de versionnage que votre code.
• Soyez précis et clair : Utilisez un langage direct et des exemples de code dans vos instructions. L’IA interprète mieux les directives claires.
• Testez et itérez : N’hésitez pas à expérimenter avec vos prompts pour voir comment l’agent réagit. C’est en itérant que vous trouverez la meilleure façon d’optimiser les résultats.

Conclusion
L’utilisation des fichiers MDC transforme l’IA générative en un véritable collaborateur d’équipe. Cette approche assure la cohérence du code, accélère les processus de développement et sert de guide pour les nouveaux membres. Bien qu’elle demande un investissement initial pour la rédaction des instructions, le gain en productivité et en qualité du code surpasse largement ce coût. En maintenant ces fichiers à jour, vous créez un standard de projet qui est compris et appliqué par tous, y compris votre agent d’IA.

L’article Prompt engineering avancé avec Github Copilot : Guider l’IA avec les fichiers Markdown custom est apparu en premier sur EKITE.

Après 15 ans d’évolution professionnelle dont la moitié dans l’agilité, je me suis senti frustré en tant que coach. Je voyais toujours les mêmes choses dans les entreprises. Les discussions chez Ekité, chez Nord Agile, avec les agilistes de la région Hauts-de-France et d’ailleurs, dans de multiples entreprises étaient toujours similaires, avec un constat partagé : les entreprises et les équipes opérationnelles parlaient d’agilité mais ne se comprennent toujours pas.

Parlaient-elles de la même chose ?

Soyons réalistes :

• La littérature est vaste autour de la culture agile plutôt opérationnelle, dans des équipes de réalisation, avec des ancrages autour de l’état d’esprit, des moyens, etc.
• Les valeurs et des principes applicables aux équipes de terrain – manifeste agile, le Cœur de l’Agilité, et d’autres choses encore – sont facilement accessibles et se diffusent depuis plus de 20 ans.
• Des éléments variés existent autour de la culture (Agile et Produit).
• Les références autour des frameworks et des certifications sont légion (que ça soit à l’échelle ou pas).

En parallèle, j’entends parler de transversalité dans les projets depuis mon début de carrière. C’est logique, dans des grandes organisations regroupant des centaines, voire des milliers de personnes, les équipes doivent bosser ensemble pour l’entreprise.

Et quand on cherche, hors de frameworks, cette liaison entre la transversalité et la culture agile, c’est un peu le désert. C’est vide, faible, absent.

C’est ainsi que quelques questions ont émergé cet été-là :

• Quid de l’agilité à un plus haut niveau d’une organisation ?
• Quid de la transversalité et de la culture agile ?
• Parler d’agilité à l’échelle, c’est légitime ou totalement à côté de la plaque ?
• Comment rendre agile ce qui est par nature complexe dans des SI tentaculaires ?
• Peut-on éviter la loi de Conway ?
• Quelles sont les valeurs à adopter pour y arriver ? Est-ce que ce sont les mêmes ? Doivent-elles être reformulées, précisées ?
• Comment la culture agile pourrait se positionner à ce niveau-là ?
• C’est quoi notre responsabilité d’agiliste ?
• [Liste non exhaustive]

J’ai donc décidé de prendre les choses en main et d’amorcer quelque chose dans le cadre de la veille : réunir des gens que j’estime, de tous horizons agiles, pour esquisser un début de vision, plus que nécessaire quand on voit fleurir partout sur les réseaux que « l’agilité est morte ». Le but était d’échanger à titre personnel et neutre. En clair, je désirais confronter nos convictions sur ce sujet pour créer quelque chose d’inédit.

Notre objectif a toujours été d’amener une culture agile transverse au sein des organisations. Culture mêlant celle du terrain, de l’organisation et de l’entreprise.

Avec quelques personnes d’expérience et alignées sur des valeurs agiles similaires et réalistes, j’estimais que nous pouvions apporter une réponse simple dans un monde complexe, à travers un format ouvert et de qualité.

Après de nombreuses rencontres, des tergiversations multiples, de la convergence avec le mouvement PAF (Post Agile Forum), nous avons trouvé le cœur de notre mission : aider les entreprises à être plus efficaces à travers nos expériences et expérimentations.

C’est ainsi qu’est née l’association Keikenchiba, qui a pour but d’organiser et de favoriser les discussions et recherches autour de l’efficacité des organisations, présentes et futures, en favorisant la collaboration et l’innovation durable, quel que soit leur niveau de complexité.

Le but secondaire est de mettre en place les éléments nécessaires à la communication des résultats de ces discussions et recherches.

Si vous désirez plus de détails sur l’histoire, avec Nicolas Tondeur, nous avons fait un lancement de l’association, disponible dans cette vidéo :

Si vous désirez nous suivre sur LinkedIn : https://www.linkedin.com/company/keikenchiba

? https://keikenchiba.org/

L’article Think Tank Agilité Transverse – the Story est apparu en premier sur EKITE.

Introduction

Et si la clé pour aligner la Direction générale, les managers et les équipes de développement tenait en un seul mot japonais : Obeya ?

Derrière ce terme qui signifie “grande salle” se cache un système de management visuel qui permet de relier la vision stratégique aux actions du quotidien. Plus qu’un outil, l’Obeya est un espace de dialogue et de pilotage qui casse les silos, facilite la prise de décision et donne de la cohérence à l’ensemble de l’organisation.

C’est un modèle que j’apprécie particulièrement, car il crée un langage commun du top management jusqu’aux équipes opérationnelles. Dans cet article, je vous propose de découvrir son origine, ses fondements, et surtout la manière dont je l’utilise concrètement pour piloter mes projets et structurer mes stratégies. Bien sûr, l’Obeya reste un outil adaptable : chaque organisation peut en ajuster la structure selon ses besoins.

1. Aux origines de l’Obeya

En japonais, Obeya signifie littéralement “grande salle”.
Ce concept a été popularisé dans les années 90 par Toyota, lors du développement de la Prius. Face à la complexité de ce projet pionnier, l’entreprise avait besoin de casser les silos et d’accélérer la prise de décision. L’idée a donc été d’installer toutes les parties prenantes – ingénieurs, designers, managers – dans une même salle, avec un mur visuel pour partager la stratégie, suivre l’avancement et identifier les blocages.

L’Obeya n’était pas seulement un outil de pilotage : c’était un véritable lieu de dialogue. Un espace où la hiérarchie s’effaçait devant la nécessité d’avancer ensemble, où chaque voix comptait, et où la stratégie se vivait au quotidien.

Depuis, le principe a évolué et s’est répandu dans d’autres secteurs : DSI, projets IT, management transversal, direction d’entreprise. Aujourd’hui, il est devenu un outil universel d’alignement stratégique et opérationnel mais peu appliqué (d’après ma vision bien sûr).

Dans ma propre expérience, nous avons vu combien l’Obeya pouvait transformer la manière de travailler : chez Electro Dépôt pour le projet Front Caisse, il a permis d’aligner plusieurs équipes techniques autour d’un même tableau de bord. Chez RS Group, il a donné une vision partagée de la stratégie du groupe. Chez Argios, il a servi de support pour relier la vision 2030 aux projets concrets de développement.

2. Les quatre grandes structures de l’Obeya

Un Obeya n’est pas un simple mur rempli de post-its. Dans ma pratique, je l’organise autour de quatre grandes structures complémentaires : la Stratégie, les Indicateurs, la Gestion des risques et le Plan de valeur.
C’est ainsi que je l’utilise pour relier la vision de la Direction aux actions concrètes des équipes.

Mais il faut garder en tête que l’Obeya reste un outil adaptable : certaines organisations ne travailleront qu’avec la stratégie et les indicateurs, d’autres iront plus loin en intégrant les risques et les dépendances. L’important n’est pas de respecter un modèle figé, mais de bâtir un espace visuel qui fait sens pour l’organisation.

A. La stratégie : la boussole commune

La première structure d’un Obeya est la Stratégie.
Elle donne la direction, rappelle le “pourquoi” et évite que les équipes se dispersent.

• On y affiche la vision de l’organisation. Exemple concret : dans l’Obeya RS Group, la vision est formulée ainsi : “Fédérer expertises et partenaires, avec humanité et innovation technologique, au service de votre développement.”

• Cette vision se décline en pans stratégiques. Dans notre cas, quatre axes clairs :

1. Développement du réseau d’influence
2. Synergie entre filiales
3. Création de nouvelles offres
4. Marketing et communication

• Chaque pan est ensuite associé à des objectifs mesurables, avec des sponsors identifiés.

 Exemple concret : le pan “synergie entre filiales” se matérialise dans l’Obeya par une frise qui relie les projets inter-entreprises, visibles en un coup d’œil.

B. Les indicateurs : le tableau de bord partagé

La deuxième structure est celle des Indicateurs.
Ici, l’objectif n’est pas de contrôler, mais de rendre visible la réalité et de donner un langage commun aux faits.

Dans ma pratique, je distingue trois niveaux :

• Les indicateurs de résultat : ils mesurent les effets concrets des actions (par exemple, l’avancement d’un projet, la satisfaction client, le chiffre d’affaires généré).

• Les indicateurs de condition : ils renseignent sur la capacité de l’organisation à délivrer (par exemple, la vélocité d’une équipe, la disponibilité des ressources, le climat social).

• Les OKR (Objectives & Key Results) : ils servent de trait d’union entre stratégie et exécution. Ils permettent de relier les objectifs globaux aux résultats attendus, en donnant de la clarté sur ce qui doit être atteint dans un temps donné.

Exemple concret : dans l’Obeya Front Caisse d’Electro Dépôt, nous suivions à la fois un indicateur de résultat (le taux de stabilité du système en caisse), un indicateur de condition (le niveau de dépendance à l’API de Boulanger) et un OKR lié à la livraison de fonctionnalités avant la rentrée.

C. La gestion des risques : anticiper plutôt que subir

Un Obeya efficace ne se limite pas à relier stratégie et indicateurs : il doit aussi intégrer une lecture claire des risques.
C’est une dimension que j’intègre systématiquement, car elle permet de rendre visibles les menaces avant qu’elles ne deviennent bloquantes.

Dans un Obeya, la gestion des risques consiste à :

• Identifier les menaces potentielles (techniques, organisationnelles, humaines, budgétaires).

• Évaluer leur probabilité d’occurrence et leur impact réel.

• Suivre les plans de mitigation ou d’actions correctives décidés par l’équipe.

• Arbitrer collectivement : un risque affiché devient un sujet partagé, non plus la responsabilité d’une seule personne.

 Exemple concret : dans l’Obeya Argios, nous avions affiché comme risque critique la dépendance à un fournisseur cloud unique. Le simple fait de le voir dans la salle a déclenché des discussions stratégiques sur la diversification et permis d’intégrer ce point dans le plan Green IT.

Autre exemple : dans l’Obeya RS Group, un risque identifié était la surcharge des équipes commerciales face aux nouvelles offres. Son affichage a permis d’anticiper des actions de soutien marketing, au lieu de laisser les équipes s’épuiser.

En rendant les risques visibles, l’Obeya change la posture de l’organisation : on passe d’une logique où l’on subit les problèmes à une logique où l’on anticipe et où l’on décide ensemble.

D. Le plan de valeur : transformer la vision en actions

La quatrième structure de l’Obeya est le Plan de valeur.
C’est ici que la stratégie prend vie et que les projets se connectent directement aux objectifs de l’organisation.

Dans ma pratique, le Plan de valeur répond à une question simple : “Quelle valeur concrète allons-nous délivrer, et à quel moment ?”

Il se compose généralement de trois éléments :

• La roadmap : une représentation visuelle, souvent par trimestre, qui montre l’enchaînement des projets et des livrables attendus.

• Le portefeuille de projets : une cartographie claire des initiatives en cours, des priorités retenues et des arbitrages réalisés.

• Les dépendances et livrables prioritaires : car dans un système complexe, la valeur ne se crée pas en vase clos. Mettre en évidence les dépendances permet d’éviter les blocages et de renforcer la collaboration entre équipes.

Exemple concret : dans l’Obeya Argios, le lancement du e-diagnostic for Personality Teams figurait dans le Plan de valeur. Il n’était pas affiché comme un simple projet, mais relié directement à la vision 2030 : “En 2030, chaque manager en Europe utilisera un e-diagnostic Argios au moins une fois par an.”
Cette mise en relation entre vision stratégique et valeur livrée a permis à chacun de comprendre pourquoi ce projet était prioritaire et comment il contribuait à l’ambition globale.

Autre exemple : dans l’Obeya RS Group, un jalon clé du Plan de valeur était l’organisation des RS Connect, non seulement comme événement interne, mais comme action concrète de synergie et de mise en avant du réseau d’influence.

En résumé, le Plan de valeur donne du sens aux actions quotidiennes. Il transforme les ambitions en une trajectoire lisible et partagée, qui permet à chacun de voir où il contribue et comment l’organisation avance collectivement.

3. L’Obeya comme fil rouge de la collaboration

Un Obeya n’est pas un poster figé que l’on colle au mur et qu’on oublie. C’est un rituel vivant, qui prend toute sa valeur lorsqu’il devient le fil rouge de la collaboration.

Concrètement, l’Obeya joue trois rôles essentiels :

• Un espace partagé de dialogue
  Il met tout le monde autour de la même table (ou du même mur) : direction, managers, équipes. En un coup d’œil, chacun voit la stratégie, les résultats, les risques et les plans. Plus besoin de rapports de 50 pages : la discussion part de faits visibles par tous.
• Un outil de rythme collectif
  L’Obeya vit au rythme de l’organisation : réunions hebdomadaires pour suivre les projets, points mensuels pour les risques, revues trimestrielles pour ajuster la stratégie. L’important est de garder une animation régulière, afin que l’Obeya reflète toujours la réalité du terrain.
• Un langage commun
  Dans des organisations complexes, chacun a souvent sa lecture des priorités. L’Obeya crée un référentiel partagé : “si ce n’est pas dans l’Obeya, ça n’existe pas.” Cette règle simple évite les discussions stériles et recentre l’énergie sur ce qui est décidé collectivement.

Exemple concret : dans l’Obeya RS Group, cette dynamique a permis de mieux connecter les filiales entre elles. En visualisant les projets transverses, les équipes ont compris qu’elles ne travaillaient pas isolément, mais qu’elles faisaient partie d’un ensemble cohérent.

Autre exemple : lors du projet Front Caisse d’Electro Dépôt, l’Obeya a permis de créer un dialogue constructif entre les développeurs et la direction, en rendant visible à la fois les résultats attendus et les risques liés aux dépendances techniques.

En somme, l’Obeya n’est pas seulement un support visuel : c’est une pratique collaborative qui transforme la manière dont les équipes et la direction interagissent. Il fluidifie la communication, facilite les arbitrages et donne une cohérence d’ensemble, du stratégique à l’opérationnel.

Imaginez un lundi matin. Toute l’équipe est rassemblée devant le mur de l’Obeya. La direction, les managers, les développeurs : tout le monde est là.
Les premiers regards se posent sur la stratégie affichée en haut du mur. Ce n’est pas une phrase abstraite dans un PowerPoint oublié : c’est le cap qui guide toutes les actions.

Juste à côté, les indicateurs attirent l’attention. Un résultat clé a progressé : la stabilité du système en caisse a atteint 99,8 %. Sourires dans l’équipe. Mais un indicateur de condition clignote : la dépendance à une API externe est critique. Ce n’est pas un chiffre froid, c’est une alerte à traiter ensemble.

La discussion s’oriente naturellement vers la gestion des risques. Le risque d’indisponibilité du fournisseur est visible pour tous. Pas besoin d’intermédiaires : la direction comprend immédiatement l’enjeu et peut arbitrer sur les solutions de contournement.

Puis on va encore plus vers la droite sur le mur : le Plan de valeur. La roadmap s’affiche clairement : livrer la nouvelle expérience caisse avant la rentrée. Tout le monde visualise ce que cela implique : les développeurs, les métiers, le management. Chacun sait où il contribue, et pourquoi cela compte.

La réunion ne dure pas deux heures. En moins de 45 minutes, les décisions clés sont prises : valider un plan B sur l’API, réaffecter une ressource sur un blocage, ajuster un OKR pour le trimestre. Tout le monde repart avec une vision claire, alignée.

C’est ça, la force de l’Obeya : il devient le fil rouge qui relie stratégie, résultats, risques et actions.
C’est aussi ce qui change la posture : au lieu de subir des décisions tombées d’en haut, chacun voit, comprend et participe à l’orientation collective.

Conclusion

L’Obeya est un outil à la fois simple et puissant.
Il ne se résume pas à un grand mur couvert de post-its, mais devient un GPS collectif : un espace où la stratégie est visible, où les résultats sont partagés, où les risques sont anticipés et où la valeur se traduit en actions concrètes.

C’est ainsi que je l’utilise dans mes projets et dans les organisations que j’accompagne. Mais il ne faut pas oublier que l’Obeya reste un outil adaptable : chaque organisation peut en ajuster la structure et le contenu, selon sa culture, sa maturité et ses priorités.

Sa véritable force réside ailleurs : dans la capacité qu’il offre à créer un langage commun entre la Direction et les équipes. Dans un monde où les projets sont complexes et les contextes mouvants, l’Obeya permet d’avancer ensemble, avec clarté et cohérence.

En résumé : si l’Obeya vit, l’organisation avance.

Références :

https://miro.com/miroverse/strategic-planning-execution-obeya-template/

https://www.planet-lean.com/articles/what-is-obeya

Obeya

From Oobeyas to iObeyas

L’article L’Obeya : de la salle de guerre japonaise au GPS collectif des entreprises est apparu en premier sur EKITE.