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.

Pas question de passer incognito : j’étais probablement l’un des seuls en costume, planqué sous un T-shirt Dragon Ball Z, fidèle à moi-même. Et justement, j’ai vu dans cette opportunité une chance unique d’aller tâter le pouls de la communauté tech — parisienne, mais pas que — en sortant le micro pour une série d’interviews façon micro-trottoir, dans le cadre de mon podcast Technologies en Pratique.

Chapitre 1 : Arrivée au Palais des Congrès de Paris

Pour rejoindre le DEVOXX, rien de plus simple : prenez le RER E depuis Gare du Nord. Pas de changement, ligne directe, et vous arrivez directement dans le Grand Palais. À croire que l’événement a été pensé pour les techs pressés — ou pour les lillois bien organisés.

Dès l’entrée, tout est bien rodé. Je me présente à l’accueil avec mon invitation speaker, et me voilà officiellement équipé : tour de cou DEVOXX… et surtout, mon badge violet. Ce badge, c’est mon Multipass. Comme dans Le Cinquième Élément. Il ouvre toutes les portes : les salles de conf, les espaces réservés, les coulisses. Une vraie clé de l’événement.

Direction vestiaire et bagagerie pour déposer tout le matos vidéo. J’ai prévu de quoi faire des interviews propres : micros, perche, batterie, trépied… bref, pas venu les mains vides.

Le DEVOXX, c’est sur deux étages, et il y a une multitude de salles de conférences. Le plus compliqué, ce n’est pas de trouver quelque chose d’intéressant… c’est de choisir. Tout a l’air passionnant, ça donne envie de se dédoubler. Mais bon, j’avais un plan : aller à la rencontre des exposants, tendre le micro, et laisser la magie opérer.

Chapitre 2 : Repérage

Le Palais des Congrès, c’est… grand. Très grand. On parle de plusieurs étages, de halls interminables, de recoins que tu découvres presque par accident. Et c’est justement au 2? étage que se cache l’un de mes terrains de jeu préférés : l’espace exposants.

Mon objectif est clair : aller à la rencontre de ceux qui développent les outils qu’on utilise chez EKITE au quotidien. Les voir en vrai, leur poser des questions simples mais directes, et comprendre leur vision, leurs enjeux, leur délire technique. Et tant qu’à y être, me laisser aussi surprendre par des technos ou des projets que je ne connais pas encore. L’idée, c’est de mixer entre valeur sûre et découverte.

Les allées sont longues, et déjà bien animées. Des stands à perte de vue, des gens qui discutent tech comme d’autres parleraient de vin, des badges qui clignotent dans tous les sens. L’ambiance est pro, mais détendue. Ça bouillonne, ça connecte, ça pitche, ça code en live. Et moi, je sens que ça va être super.

Chapitre 3 : Premier interview – Michelin

Quand on me dit Michelin, je pense bagnoles, F1, gomme qui accroche et guide rouge. Pas forcément tech. Et pourtant… me voilà nez à nez avec un stand Michelin, en plein cœur de l’espace exposants du DEVOXX.

Je n’ai pas prévu de parler de pneus — même si, entre nous, je suis fan de voiture et de Formule 1. Non, là je suis venu pour parler tech. Avec des vrais techs. Et je tombe sur Jérémy FLAGEL, tech lead chez Michelin, qui accepte direct de jouer le jeu et de représenter fièrement sa boîte au micro.

Bonne pioche. Jérémy est détendu, clair, passionné. Il incarne bien cette génération de tech leads qui savent mêler exigence et accessibilité. L’interview se déroule tranquillement, sans stress, en mode conversation. On parle d’architecture, d’usage terrain, de contraintes industrielles… et franchement, ça casse les idées reçues.

Oui, il y a de la vraie tech chez Michelin. Et elle mérite clairement d’être entendue.

Chapitre 4 : Clever Cloud

Nouvelle cible : Clever Cloud. Et pas n’importe qui au micro : Steven Leroux, le big boss de la tech. CTO de la boîte. Rien que ça.

Steven m’accorde de son temps malgré un petit handicap du moment — il s’est blessé récemment et se déplace avec une béquille. Mais vous ne la verrez pas à l’image : à peine le micro sorti, il l’a balancée par terre, comme pour dire « l’interview, c’est sacré ». Autant dire que le ton est donné.

Steven, c’est du solide. Clair, précis, pas là pour faire du bullshit. Il sait où il va, il connaît son sujet sur le bout des doigts, et surtout, il sait le partager. On parle techno bien sûr, mais aussi vision, stratégie, et tendances à venir chez Clever Cloud. Il a ce truc rare : la capacité à rendre limpide des sujets complexes, sans jamais perdre en profondeur.

Je sens qu’il a l’habitude des projecteurs, mais il garde une énergie sincère. C’est pro, c’est vivant, et pour moi, c’est exactement le genre de moment que je venais chercher ici.

Chapitre 5 : JetBrains

Bingo ! Là, c’est pas un, mais deux développeurs de chez JetBrains que j’arrive à avoir au micro : Louis et Joffrey. Jackpot total.

Mais ça n’a pas été simple. Avant d’en arriver là, j’ai dû passer par la case négociation avec la responsable marketing. Et je peux vous dire qu’elle protège bien ses équipes. Normal : JetBrains, c’est du sérieux. Mon podcast n’est pas un média officiel, je ne suis pas journaliste, je suis juste… moi.

Alors je lui dis : « Je suis entrepreneur, delivery manager, et surtout passionné par notre secteur : l’IT. » Ces quelques mots ont suffi à désamorcer la méfiance. Elle a vu que je n’étais pas là pour piéger ou faire du buzz, mais pour partager. Résultat : une belle interview, posée, humaine, technique, avec deux devs très pros et accessibles.

Et en bonus, j’ai même réussi à glisser une petite blague pendant l’enregistrement. Si vous tendez bien l’oreille… vous verrez si elle fait mouche.

Chapitre 6 : Sonar

J’ai une longue histoire avec Sonar. Cet outil, je l’utilise depuis plus de 15 ans. Alors forcément, en venant au DEVOXX, je m’étais fixé un objectif : interviewer quelqu’un de chez eux. Pas négociable.

Sauf que ça n’a pas été une promenade de santé. Premier essai : la personne ne sait pas me répondre. Deuxième essai : “Attendez, c’est peut-être bidule qui peut faire ça.” Troisième : “Ah non, finalement, faut voir avec Sylvain.” Quatrième tentative… jackpot. C’est bon, j’ai la personne.

Sylvain, donc. Grand timide. Et aussi… plus grand que moi. Il faut le dire.

Je sens direct qu’il est pas super à l’aise avec le micro. Alors je reviens à ma méthode : désamorçage. « Je ne suis pas un média, je ne viens pas faire une interview pour buzzer. Je suis un passionné d’IT, un utilisateur de Sonar de la première heure. Je viens juste partager une belle histoire. » Et je lui raconte justement mon histoire avec Sonar, les projets où il m’a sauvé la vie, les bugs évités, la dette technique tenue à l’œil…

Petit à petit, Sylvain se détend. Il sourit. Et finalement, on y va. Une interview honnête, sans fioriture, avec quelqu’un de sincère. Une belle boucle bouclée pour moi.

Chapitre 7 : MongoDB

Décidément, après Sonar, j’ai droit au même scénario avec MongoDB : plusieurs tentatives, plusieurs détours… mais au final, j’ai réussi. Et cette fois, c’est grâce à la gentillesse de Cécile Chen que j’ai pu interviewer Loïc Formont.

Encore un grand timide — et encore un plus grand que moi (je commence à croire que c’est un critère). Pas très à l’aise avec l’exercice. Alors je dégaine mon arme secrète : l’auto-dérision.

Je lui dis : “Je vais t’interviewer comme un tonton relou qui comprend rien à la tech.” Ce qui, soyons honnêtes, n’est pas entièrement faux. Et là, ça le fait marrer. La pression retombe, l’ambiance se détend, et on lance l’enregistrement.

Au final, c’était l’exo parfait pour lui : parler simplement de ce qu’il fait, vulgariser, partager. Une interview authentique, sans chichi, exactement comme j’aime.

Cerise sur le gâteau : Loïc vient aussi au Devlille cette année. Du coup, je lui ai glissé une invitation pour un futur épisode de La Voix de l’Innovation. L’histoire continue.

Conclusion : déjà fini ?

C’est passé à une vitesse folle.

Trois jours de DEVOXX, c’est intense. Il y a tellement de choses à voir, à découvrir, à comprendre… Tellement de personnes à croiser, à écouter, à interviewer. Des passionnés de la tech, comme on les aime. Authentiques, accessibles, fiers de ce qu’ils construisent.

J’ai vécu ces journées comme une immersion dans le cœur battant de notre secteur. J’y suis allé avec un micro, une envie de partager, et l’énergie d’un delivery manager en T-shirt DBZ et costume. Et je repars avec des rencontres marquantes, des échanges riches, et surtout une confirmation : la tech, quand elle est humaine, curieuse et ouverte, c’est vraiment ce qui me fait vibrer.

Vivement la prochaine.

L’article Quand un delivery manager en costume et T-shirt DBZ infiltre le DEVOXX 2025… est apparu en premier sur EKITE.

Dans un monde de plus en plus axé sur le numérique, avoir un portfolio en ligne est essentiel pour tout professionnel créatif.

En tant que designer, il est très important d’avoir un portfolio pour mettre en avant ses expériences passées et présentes, ses passions, ses envies, etc. Le fait est que, en tant que bon UI designer qui se respecte, les connaissances en développement sont présentes, mais la mise en place est fastidieuse, chronophage et le résultat est trop souvent en deçà des attentes. Heureusement, aujourd’hui certaines entreprises nous offrent la possibilité de nous faciliter la vie avec des outils no-code et nous proposent des solutions plus ou moins personnalisables. Et au fil de mes recherches, un outil revenait très souvent au centre de l’attention : Framer.

Dans cet article, nous plongerons dans les entrailles de Framer pour découvrir ce dont il est réellement capable et s’il répond bel et bien à toutes ses belles promesses.

Framer, qu’est-ce que c’est ?

Avant de plonger dans la création de notre portfolio, jetons un coup d’œil à ce qu’est Framer. Il s’agit d’une puissante plateforme de prototypage qui permet aux concepteurs de créer des prototypes interactifs et réalistes pour diverses applications et interfaces utilisateur.

Framer propose de nombreuses fonctionnalités qui facilitent la conception :

• Des composants intelligents : il offre une conception simplifiée, élément par élément et sans lignes de code.
• Des modèles prédéfinis : grâce à une bibliothèque regroupant des modèles (application mobile, lecteur musical, etc.), des options d’interactions, de superpositions, de transitions ou encore d’effets, il est facile de mettre en œuvre vos idées.
• Des tests utilisateurs : la solution propose des options d’arrière-plans et de cadres à personnaliser, permettant de présenter votre travail. Il suffit ensuite de partager un lien pour rendre votre prototype accessible à des utilisateurs tiers.
• Un espace collaboratif : il est possible de donner accès à tous les acteurs de la conception. L’outil offre la possibilité d’intégrer des collaborateurs externes et de contrôler les accès ainsi que les partages.
• Récemment, Framer a intégré OpenAI, ce qui permet de créer rapidement des landing pages à partir de divers templates personnalisables.

Prise en main

Pour commencer, familiarisons-nous avec l’interface de Framer et les outils disponibles pour créer notre portfolio.

L’interface de Framer présente des similitudes frappantes avec de nombreux autres outils de création tels que Figma. Elle est particulièrement conviviale et intuitive, évitant les pièges rencontrés dans d’autres outils où l’utilisateur est submergé par une surcharge d’informations dès le début de son parcours, ce qui rend son utilisation rapidement ardue.

L’interface se divise en trois parties principales :

1. Le canva au centre de l’écran : C’est ici que se trouve notre projet, avec la possibilité de définir dès le début les breakpoints pour visualiser le responsive et corriger d’éventuelles erreurs.
2. Une barre latérale (à gauche) : Elle offre trois options principales (les différentes pages, les calques et les éléments graphiques) et est toujours visibles pour faciliter la navigation.
3. Une barre latérale (à droite) : C’est ici que nous trouvons toutes les options de mise en page et d’animations. Elle utilise les termes familiers de CSS pour éviter toute confusion et offre une grande variété d’options de personnalisation de base.

Présentation du projet

Bon, maintenant que nous avons posé les bases, il est temps de nous plonger dans la création de ce portfolio. J’ai décidé de rester relativement simple en mettant en place une page d’accueil et une page détaillant chaque projet.

Dès mes premiers pas sur Framer, j’ai pu constater sa facilité de prise en main et à quel point il se rapproche des nombreuses fonctionnalités que nous retrouvons sur Figma en termes de mise en page.

Au début du projet, je pensais importer directement mon projet Figma dans Framer et apporter les modifications nécessaires pour rendre la maquette viable. Cependant, je me suis rapidement rendu compte qu’il n’était pas si difficile de créer directement dans Framer (Presque moins difficile que de préparer correctement un fichier figma). C’est donc ce que j’ai fait pour l’ensemble du projet.

Animations

Ce qui m’a particulièrement attiré chez Framer, c’est la promesse de pouvoir créer des animations complexes sans se prendre la tête avec des montagnes de code ou d’autres solutions bien trop compliquées à prendre en main.

Et encore une fois, j’ai été impressionné par la facilité d’utilisation de ces options. Pour créer des animations, nous disposons d’un volet « Effets » qui se divise en deux parties :

• Les animations liées à une interaction (clic, survol, glisser-déposer)
• Les animations liées au défilement (vitesse de défilement, transformations au défilement et animations au défilement)

Cela peut sembler limité, cependant, c’est amplement suffisant pour offrir une personnalisation pratiquement infinie et précise. J’ai pu mettre en place une grande variété d’animations au sein de mon portfolio, et tout s’est déroulé parfaitement et facilement.

Parti CMS

Pour la création des pages projet de mon portfolio, j’ai pu explorer la partie CMS de Framer. Celle-ci est particulièrement bien conçue et nous propose de créer différentes « Collections » (bases de données). Pour les remplir, nous avons plusieurs possibilités :

• Remplir manuellement via l’interface en ajoutant des champs de différents types (image, texte, ID, etc.).
• Importer un fichier CSV contenant l’intégralité de notre base de données. Cette option fonctionne très bien mais ne permet pas d’importer des images (sauf si celles-ci sont hébergées).

Grâce à cela, nous avons pu nous lancer dans la création de notre modèle de page projet, et, une fois de plus, Framer nous a grandement facilité la tâche en proposant une interface parfaite. Lorsque nous ajoutons un élément et que nous souhaitons le rendre dynamique, il suffit de cliquer sur le petit plus à côté des options de personnalisation pour définir la bonne donnée.

En définitive, cette partie du site a pu être réalisée extrêmement rapidement.

Framer x Figma

Une des nombreuses possibilités offertes par Framer est la capacité de récupérer directement les maquettes réalisées dans Figma pour les importer dans Framer et les éditer directement. C’est cette fonctionnalité qui m’a particulièrement attiré sur le logiciel car la promesse est folle : transformer des maquettes en site fonctionnel en un simple copier-coller.

Dans les faits, c’est effectivement bluffant. Après avoir utilisé le plugin Framer dans Figma, je me retrouve avec une page identique directement dans Framer. Toutefois, il faut faire particulièrement attention à la création de la maquette au préalable, car Framer doit pouvoir comprendre les différents éléments et leur comportement attendu. Cela nécessite donc de prêter une attention particulière aux contraintes et aux auto-layout que nous mettrons en place dans notre projet.

Par exemple, voici une grille sans aucun auto-layout ni contraintes. Évidemment, Framer ne parvient pas à identifier les éléments, ce qui nous donne un résultat absolument non responsive et inutilisable.

Et voici la version avec tout bien fait.

Résultat

Et voilà, nous arrivons à la fin de la création de ce portfolio, et pour être tout à fait honnête, je suis bluffé par la qualité de l’outil, sa facilité de prise en main et les possibilités qui me semblent aujourd’hui presque infinies.

Dans le cadre de cet article, j’ai fait le choix de ne pas utiliser une version payante pour m’assurer de sa viabilité, et je n’ai absolument pas été limité par celle-ci, à l’exception de trois choses :

• L’URL n’est pas personnalisable.
• Il n’est pas possible d’importer des vidéos.
• Un blason “Made in Framer” trône fièrement en bas à droite en position fixe.

Voici ce à quoi ressemble donc le portfolio pour le moment !

[videopress SASO4nzL]

En conclusion

En conclusion, je pense que Framer est l’outil idéal, particulièrement adapté aux designers. Tout au long de la création de mon portfolio et de l’apprentissage de l’outil, je n’ai à aucun moment eu l’impression de perdre mon temps. Chaque fois que je rencontrais une difficulté, j’ai eu la merveilleuse surprise de découvrir toute la documentation proposée par Framer et par la communauté, qui s’avère être particulièrement active. Cela en fait, selon moi, l’outil le plus apte à répondre aux attentes des designers web.

L’article Concevoir un portfolio avec Framer est apparu en premier sur EKITE.

mkdir demo-custom-provider && cd demo-custom-provider
git clone git@github.com:ekit3/terraform-custom-provider.git

Dans un premier temps, placez-vous dans le dossier, « custom-provider/resources/terraform-provider-courses », il s’agit du boilerplate de départ.

Explication du contenu de ce dossier.
Le dossier « courses » contient le premier fichier de code go pour notre futur provider. Celui-ci initialise un provider, mais vide !

package courses

import (
    "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
)

// Provider -
func Provider() *schema.Provider {
    return &schema.Provider{
        ResourcesMap:   map[string]*schema.Resource{},
        DataSourcesMap: map[string]*schema.Resource{},
    }
}

Le fichier « main.go », est le point d’entrée de notre provider.

package main

import (
    "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
    "github.com/hashicorp/terraform-plugin-sdk/v2/plugin"

    "terraform-provider-courses/courses"
)

func main() {
    plugin.Serve(&plugin.ServeOpts{
        ProviderFunc: func() *schema.Provider {
            return courses.Provider()
        },
    })
}

Le dossier « terraform », contient le code Terraform qui appelera notre custom provider.

terraform {
  required_providers {
    courses = {
      version = "0.1"
      source  = "hashicorp.com/ekite/courses"
    }
  }
}

provider "courses" {}

Le « Makefile », qui lui nous permettra de build et installer notre provider sur notre machine. Vous remarquerez que les informations décrites dans ce fichier correspondent à l’appel du provider, dans le fichier ci-dessus.

TEST?=$$(go list ./... | grep -v 'vendor')
HOSTNAME=hashicorp.com
NAMESPACE=ekite
NAME=courses
BINARY=terraform-provider-${NAME}
VERSION=0.1
OS_ARCH=darwin_amd64

default: install

build:
    go build -o ${BINARY}

release:
    GOOS=darwin GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_darwin_amd64
    GOOS=freebsd GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_freebsd_386
    GOOS=freebsd GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_freebsd_amd64
    GOOS=freebsd GOARCH=arm go build -o ./bin/${BINARY}_${VERSION}_freebsd_arm
    GOOS=linux GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_linux_386
    GOOS=linux GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_linux_amd64
    GOOS=linux GOARCH=arm go build -o ./bin/${BINARY}_${VERSION}_linux_arm
    GOOS=openbsd GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_openbsd_386
    GOOS=openbsd GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_openbsd_amd64
    GOOS=solaris GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_solaris_amd64
    GOOS=windows GOARCH=386 go build -o ./bin/${BINARY}_${VERSION}_windows_386
    GOOS=windows GOARCH=amd64 go build -o ./bin/${BINARY}_${VERSION}_windows_amd64

install: build
    mkdir -p ~/.terraform.d/plugins/${HOSTNAME}/${NAMESPACE}/${NAME}/${VERSION}/${OS_ARCH}
    mv ${BINARY} ~/.terraform.d/plugins/${HOSTNAME}/${NAMESPACE}/${NAME}/${VERSION}/${OS_ARCH}

test: 
    go test -i $(TEST) || exit 1                                                   
    echo $(TEST) | xargs -t -n4 go test $(TESTARGS) -timeout=30s -parallel=4                    

testacc: 
    TF_ACC=1 go test $(TEST) -v $(TESTARGS) -timeout 120m

Nous allons maintenant build cette première version de notre provider, pour ce faire placez vous dans le dossier « custom-provider/resources/terraform-provider-courses »

On initialise notre module go. Le nom choisi ici doit matcher le nom choisi dans le ‘main.go’ au niveau des imports.

go mod init terraform-provider-courses

On installe les dépendances, de notre module

go mod tidy

Après cela, nous pouvons utiliser notre Makefile pour build et installer notre module

make build && make install

terraform init
terraform plan

docker-compose up -d

Ces routes sont disponibles dans l'api,
GET   http://localhost:4000/cours, renvoie une liste de cours
POST http://localhost:4000/cours, crée un cour avec ce body 
{
    "name": "Petit intervention",
    "time": 60,
    "summary": "intervention sur sujet tech"
}
PUT http://localhost:4000/cours/651fc2f3970d6264792bf49e, avec le même body que pour le POST
DELETE http://localhost:4000/cours/65201115d9a28e309a48d610, qui supprime le cours.

terraform init --upgrade
terraform plan

package courses

import (
    "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
)

// Provider -
func Provider() *schema.Provider {
    return &schema.Provider{
        ResourcesMap: map[string]*schema.Resource{
            "ekite_cour": dataSourceCour(),
        },
        DataSourcesMap: map[string]*schema.Resource{
            "ekite_courses": dataSourceCourses(),
        },
    }
}

package courses

import (
    "bytes"
    "context"
    "encoding/json"
    "log"
    "net/http"

    "github.com/hashicorp/terraform-plugin-sdk/v2/diag"

    "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
)

type Cour struct {
    Id      string `json:"_id"`
    Name    string `json:"name"`
    Time    int    `json:"time"`
    Summary string `json:"summary"`
}

func dataSourceCour() *schema.Resource {
    return &schema.Resource{
        CreateContext: resourceCourCreate,
        ReadContext:   resourceCourRead,
        UpdateContext: resourceCourUpdate,
        DeleteContext: resourceCourDelete,

        Schema: map[string]*schema.Schema{
            "_id": &schema.Schema{
                Type:     schema.TypeString,
                Optional: true,
            },
            "name": &schema.Schema{
                Type:     schema.TypeString,
                Required: true,
            },
            "time": &schema.Schema{
                Type:     schema.TypeInt,
                Required: true,
            },
            "summary": &schema.Schema{
                Type:     schema.TypeString,
                Required: true,
            },
        },
    }
}

func resourceCourCreate(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {

    var diags diag.Diagnostics

    name := d.Get("name").(string)
    time := d.Get("time").(int)
    summary := d.Get("summary").(string)

    data := map[string]interface{}{
        "name":    name,
        "time":    time,
        "summary": summary,
    }

    jsonData, err := json.Marshal(data)

    resp, err := http.Post("http://localhost:4000/cours", "application/json", bytes.NewBuffer(jsonData))

    if err != nil {
        log.Fatal(err)
    }
    defer resp.Body.Close()
    cour := &Cour{}
    err = json.NewDecoder(resp.Body).Decode(&cour)
    if err != nil {
        return diag.FromErr(err)
    }
    // THIS IS MANDATORY FOR TERRAFORM TO BE ABLE TO GARANT CONSISTENCY OF YOUR RESOURCES
    d.SetId(cour.Id)
    return diags
}

func resourceCourRead(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {

    return nil
}

func resourceCourUpdate(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {

    return nil
}

func resourceCourDelete(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {

    return nil
}

terraform {
  required_providers {
    courses = {
      version = "0.0.2"
      source  = "hashicorp.com/ekite/courses"
    }
  }
}

resource "ekite_cour" "mon_cour" {
  provider = courses
  name = "Cour créé depuis terraform"
  time = 60
  summary = "Un simple exemple"
}

package courses

import (
    "bytes"
    "context"
    "encoding/json"
    "log"
    "net/http"
    "time"

    "github.com/hashicorp/terraform-plugin-sdk/v2/diag"

    "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
)

type Cour struct {
    Id      string `json:"_id"`
    Name    string `json:"name"`
    Time    int    `json:"time"`
    Summary string `json:"summary"`
}

func dataSourceCour() *schema.Resource {
    return &schema.Resource{
        CreateContext: resourceCourCreate,
        ReadContext:   resourceCourRead,
        UpdateContext: resourceCourUpdate,
        DeleteContext: resourceCourDelete,

        Schema: map[string]*schema.Schema{
            "_id": &schema.Schema{
                Type:     schema.TypeString,
                Optional: true,
            },
            "name": &schema.Schema{
                Type:     schema.TypeString,
                Required: true,
            },
            "time": &schema.Schema{
                Type:     schema.TypeInt,
                Required: true,
            },
            "summary": &schema.Schema{
                Type:     schema.TypeString,
                Required: true,
            },
            "last_updated": &schema.Schema{
                Type:     schema.TypeString,
                Optional: true,
                Computed: true,
            },
        },
    }
}

func resourceCourCreate(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {

    var diags diag.Diagnostics

    name := d.Get("name").(string)
    time := d.Get("time").(int)
    summary := d.Get("summary").(string)

    data := map[string]interface{}{
        "name":    name,
        "time":    time,
        "summary": summary,
    }

    jsonData, err := json.Marshal(data)

    resp, err := http.Post("http://localhost:4000/cours", "application/json", bytes.NewBuffer(jsonData))

    if err != nil {
        log.Fatal(err)
    }
    defer resp.Body.Close()
    cour := &Cour{}
    err = json.NewDecoder(resp.Body).Decode(&cour)
    if err != nil {
        return diag.FromErr(err)
    }
    // THIS IS MANDATORY FOR TERRAFORM TO BE ABLE TO GARANT CONSISTENCY OF YOUR RESOURCES
    d.SetId(cour.Id)
    return diags
}

func resourceCourRead(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {
    var diags diag.Diagnostics
    client := &http.Client{Timeout: 10 * time.Second}

    url := "http://localhost:4000/cours/" + d.Id()

    req, err := http.NewRequest("GET", url, nil)
    if err != nil {
        return diag.FromErr(err)
    }

    r, err := client.Do(req)
    if err != nil {
        return diag.FromErr(err)
    }
    defer r.Body.Close()
    cour := &Cour{}
    err = json.NewDecoder(r.Body).Decode(&cour)
    if err != nil {
        return diag.FromErr(err)
    }
    d.Set("name", cour.Name)
    d.Set("time", cour.Time)
    d.Set("summary", cour.Summary)

    return diags
}

func resourceCourUpdate(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {
    client := &http.Client{Timeout: 10 * time.Second}
    name := d.Get("name").(string)
    timeobj := d.Get("time").(int)
    summary := d.Get("summary").(string)

    data := map[string]interface{}{
        "name":    name,
        "time":    timeobj,
        "summary": summary,
    }

    jsonData, err := json.Marshal(data)

    url := "http://localhost:4000/cours/" + d.Id()

    req, err := http.NewRequest(http.MethodPut, url, bytes.NewBuffer(jsonData))
    if err != nil {
        log.Fatal(err)
    }
    req.Header.Set("Content-Type", "application/json; charset=utf-8")
    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    // THIS IS MANDATORY FOR TERRAFORM TO BE ABLE TO GARANT CONSISTENCY OF YOUR RESOURCES
    d.Set("last_updated", time.Now().Format(time.RFC850))
    return resourceCourRead(ctx, d, m)
}

func resourceCourDelete(ctx context.Context, d *schema.ResourceData, m interface{}) diag.Diagnostics {
    var diags diag.Diagnostics
    client := &http.Client{}
    url := "http://localhost:4000/cours/" + d.Id()
    req, err := http.NewRequest("DELETE", url, nil)
    if err != nil {
        panic(err)
    }
    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    // THIS IS MANDATORY FOR TERRAFORM TO BE ABLE TO GARANT CONSISTENCY OF YOUR RESOURCES
    d.SetId("")
    return diags
}

L’article Terraform custom provider est apparu en premier sur EKITE.

Problème : bien souvent, ces solutions Cloud sont une boîte noire et au-delà de la facture correspondant aux ressources utilisées, il est à minima difficile d’en savoir plus sur la façon dont fonctionnent les fournisseurs de service Cloud, notamment sur le sujet du green IT. Parce que oui, si vous passez des heures à retravailler et limiter vos requêtes, que vos fonctionnalités sont sobres mais que l’hébergement Cloud que vous utilisez a pour principale source d’énergie une centrale à charbon, c’est pour le moins dommage. De même, si vos instances sont montées en permanence alors qu’elles connaissent des périodes de moindre utilisation (voire d’absence totale), on perd un peu de l’intérêt du green IT. Et enfin, il n’est pas toujours facile de se faire entendre sur ces questions, surtout quand les objectifs (de sprint, de produit, de politique d’entreprise) sont plus focalisés sur la performance économique que sur la préservation de la planète. 

Aujourd’hui, l’objectif est donc d’aborder ces différents sujets. D’une part, comment améliorer la consommation de ressources d’un cluster Cloud et de l’autre, comment adapter les KPI traditionnels, prisés par les directions financières, afin de les mettre au service d’une cause plus grande.

« C’est pas Versailles ici », ou comment optimiser son Cloud

Si la lecture du titre de cette partie vous a rappelé des souvenirs ou que vous vous êtes vous-même surpris ou surprise à prononcer ces mots, ces quelques paragraphes devraient vous parler. En effet, alors qu’on éteint la lumière lorsqu’on quitte une pièce, comment justifier de laisser des ressources informatiques allumées en continu, même lorsqu’elles ne sont pas utilisées ? Prenons l’exemple de vos environnements de recette et de développement : en dehors des heures de bureau, y a-t-il le moindre intérêt à les faire fonctionner, si ce n’est brûler (littéralement) du gaz et remplir les poches de Google et Amazon ? Des améliorations concrètes et rapides sont donc faciles à aller chercher (dans un premier temps). C’est le service que propose Kube-green, plug-in rapide à mettre en place (en 30 minutes c’est largement fait) et diablement efficace. Dans l’exemple qu’on trouve dans leur documentation, la mise en place d’une gestion très simple d’un cluster permet de réduire de près de 30% les émissions de gaz à effet de serre (GES) et jusqu’à 37% sur un cluster plus important. Rendez-vous compte : cela fait plus d’un tiers d’économie en quelques réglages. 

Remarque : le calcul de l’empreinte carbone se base sur un article rédigé par GoClimate et qui donne des estimations en fonction du type d’hébergement choisi.

OK, qu’est-ce que ça donne concrètement ?

Pour le tester, j’ai démarré un cluster Kubernetes en local, sur lequel j’ai créé un namespace, au sein duquel j’ai déployé une API, un front et une base de données. Ensuite, il m’a de lancer cette commande :

kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml

Après quelques secondes, Kube-green était déployé dans mon cluster, au niveau global. J’ai ensuite appliqué ce fichier, dans le même namespace où j’ai déployé mes applications.

apiVersion: kube-green.com/v1alpha1
kind: SleepInfo 
metadata: 
  name: sleep-test 
  Namespace: app-example 
spec: 
  weekdays: "*" 
  sleepAt: "*:*/5" 
  wakeUpAt: "*:*/7"

Dans celui-ci est écrit que je souhaite scale down tous les déploiements de ce namespace, tous les jours, à chaque 5ème minute de chaque heure et de la même manière, scale up à chaque 7ème minute (l’exemple n’a pas vraiment de sens, il s’agit là plutôt d’illustrer la syntaxe, il y a évidemment d’autres manières de configurer cette partie). On peut décider d’ignorer certaines ressources, ou de stopper également ou uniquement des cronjobs. Vous pouvez trouver ces informations dans la doc de Kube-green, que l’on peut remercier pour sa clarté. Si on observe les Pods du namespace ,on voit bien qu’ils se coupent et s’allument comme désiré :

Certes, cette solution n’est qu’un début, mais pourquoi ne pas aller plus loin ? On peut imaginer répliquer ce système pour ajouter les jours fériés, les pauses-repas, et ensuite en production, en adaptant le nombre de nœuds disponibles en fonction de l’activité prévue.

Il existe encore d’autres solutions, comme KEDA, qui permettent d’être encore plus flexible dans les choix de scalabilité. Cet outil, en plus de reprendre les fonctionnalités de Kube-green, permet d’allumer et d’éteindre nos composants Kubernetes en suivant des métriques que vous pouvez personnaliser à volonté, au lieu de vous baser sur des métriques classiques, comme le niveau d’activité du CPU ou de la RAM. On peut imaginer scale sur un indicateur qui mesure le trafic, ou bien qui va chercher des informations en base de données. Par exemple une quantité de data à intégrer, ou encore une métrique personnalisée qui remonterait la consommation en euros (ou en CO2 ?) pour les limiter. KEDA est certes plus compliqué à mettre en place et à tester mais il vaut le coup qu’on s’y intéresse.

C’est bien beau vos histoires mais comment je vends ça moi ?

Ce qui est certain c’est qu’aujourd’hui les directions financières ont un objectif sur les questions d’argent plutôt que sur celles de la biodiversité ou de la sobriété énergétique (et en même temps, tant qu’on les appellera des directions financières…). C’est pour ça qu’il va falloir ruser : plutôt que de mentionner la diminution du bilan carbone de votre application, il vaudra toujours mieux mettre en avant la baisse de la facture de votre infrastructure (forcément, si on utilise moins de ressources, on émet moins de GES et on paie moins cher). En revanche, pour donner un objectif à vos équipes sensibles à ces questions, d’autres outils existent et notamment Kube Carbon.

Introduit en 2019 par Adam Hevenor, cet outil permet facilement de générer des courbes et des métriques suivant les émissions de GES de votre activité. Dans un article partagé sur Medium, il détaille son calcul de manière à faire le lien entre volume d’opérations informatiques et émission de gaz à effet de serre. La méthodologie n’est pas parfaite, et certains chiffres mériteraient sans doute d’être revus (la publication date déjà d’octobre 2019), mais elle explore néanmoins les différentes questions qui se posent à l’heure où l’usage du Cloud se démocratise. Quelle est l’empreinte carbone des services Cloud de Google ou d’Amazon ? Les deux vous répondront qu’ils sont neutres en carbone mais ce tour de passe-passe n’est possible que grâce à l’achat de crédits carbone et autres compensations, le tout sans avoir la moindre transparence concernant les volumes d’équivalent CO2 produits. C’est d’ailleurs la conclusion de l’article d’Adam qui appelle de ses vœux les grands du Cloud à plus de transparence sur ces questions (d’ailleurs ils pourraient intégrer à leur service le même type de graphes de façon native). Surtout, dans une période qui appelle à la sobriété, tout ce qu’il n’est pas nécessaire de compenser est bon à prendre.

Kube Carbon a donc cet avantage de fournir une vision chiffrée de votre impact carbone, avec pour objectif de devenir un indicateur important pour l’ensemble des acteurs.

OK, vous pouvez me refaire un topo pratique aux petits oignons comme pour Kube-green ?

Kube Carbon, techniquement, se résume à un dashboard Grafana, qui, dans l’état, ne fait que prendre des métriques, les transformer et nous les afficher. Ce qu’il faut retenir c’est la réflexion qu’a eu Adam Hevenor autour de ces indicateurs. Pour mieux me rendre compte de ce que cela représente, j’ai quand même déployé Prometheus, Grafana et importé ce dashboard.

Toujours sur mon cluster k8s local, j’ai exécuté ces commandes :

// create dedicated namespace and switch to it 
k create ns prometheus 
kubens prometheus 
// helm install for prometheus & grafana 
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts  
helm repo update 
helm install prometheus prometheus-community/prometheus 
helm repo add grafana https://grafana.github.io/helm-charts  
helm repo update 
// Expose grafana svc to local access 
kubectl expose service grafana --type=NodePort --target-port=3000 --name=grafana-ext 
// Get svc port for access

// Get secret data to log in grafana 
k get secret  grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

sum(container_cpu_usage_seconds_total * (.001/$flops_per_watt*$carbon_per_watt*$clock_speed)) / 1000000000

L’article Du green dans ton Cloud est apparu en premier sur EKITE.