Monter une équipe d'agents avec Claude Code​

Claude Code n'est plus seulement "un assistant qui code dans le terminal". Avec les subagents, les skills, les hooks, et les serveurs MCP (Model Context Protocol), on peut construire quelque chose qui ressemble à une vraie squad produit, sauf que chaque rôle est un agent spécialisé, avec son propre contexte, ses propres outils, et une mission bien définie.

J'ai fini par structurer une "équipe" de six agents (PO, PM, Tech Lead, Devs, Testeurs, UI/UX Designer) autour de Claude Code, connectée à Figma pour le design et Linear pour le ticketing. Pas parce que c'était le plan de départ : au début je n'avais qu'un seul agent générique, et je passais mon temps à lui répéter le contexte du projet à chaque nouvelle tâche. Découper mes actions en rôles a réglé ça presque par hasard. Je vous explique comment j'ai construit tout ça, et où ça coince encore.

Subagents ou Agent Teams ?​

Deux briques Claude Code rendent ça possible, et elles ne se valent pas pour tous les usages.

Les subagents sont des assistants spécialisés, définis en Markdown avec un frontmatter (nom, description, outils autorisés), stockés dans .claude/agents/ (au niveau projet) ou ~/.claude/agents/ (au niveau utilisateur). Chaque subagent tourne dans sa propre fenêtre de contexte, avec un system prompt dédié et un accès aux outils restreint. Claude délègue automatiquement une tâche au subagent dont la description correspond, ou vous l'invoquez explicitement.

Les Agent Teams, plus récentes et encore en évolution rapide, proposent un modèle où plusieurs agents collaborent activement, se répartissent le travail et se débloquent mutuellement, un peu comme un sprint Scrum plutôt qu'un simple MapReduce de workers indépendants. J'ai testé, et honnêtement ce n'est pas encore le confort auquel on s'attend : les reprises de session sont fragiles et la consommation de tokens grimpe vite dès que plusieurs agents discutent entre eux.

Pour une squad produit complète, l'analogie la plus juste reste : le PO/PM/Tech Lead orchestrent, les devs et testeurs exécutent en parallèle.

Définir les rôles​

Chaque rôle devient un fichier .claude/agents/<role>.md avec un frontmatter qui déclare

• name : l'identifiant de l'agent
• description : ce qui déclenche sa délégation automatique
• et tools/disallowedTools : les outils qu'il a le droit d'utiliser (Un PO ne devrait pas avoir accès à Write/Edit sur le code, un dev n'a pas forcément besoin d'écrire dans Linear directement, etc).

Ce qui donne dans notre contexte :

Product Manager (pm.md) : porte la vision produit, arbitre les priorités, découpe en épics/releases, garde la cohérence globale. Accès Linear (projets, roadmap), lecture Figma.

---
name: pm
description: Porte la vision produit, arbitre les priorités, découpe un besoin en épics. À invoquer pour tout cadrage produit de haut niveau.
tools: Read, Grep, Glob, mcp__linear
---

Tu es le Product Manager de l'équipe. Pour chaque besoin reçu :
1. Vérifie qu'il s'inscrit dans la roadmap produit.
2. Formalise le besoin en épic, avec son objectif métier.
3. Cherche dans Linear un projet existant correspondant avant d'en créer un. Réutilise-le si trouvé, crée-le sinon.
...

Product Owner (po.md) : traduit un besoin métier en user stories priorisées, avec critères d'acceptation clairs. Accès Linear en lecture/écriture, pas d'accès au code.

---
name: po
description: Traduit un besoin métier en user stories priorisées avec critères d'acceptation. À invoquer pour tout découpage fonctionnel.
tools: Read, Grep, Glob, mcp__linear
---

Tu es le Product Owner de l'équipe. Pour chaque besoin reçu :
1. Rédige des user stories au format "En tant que... je veux... afin de...".
2. Ajoute des critères d'acceptation clairs et testables pour chacune.
3. Priorise les stories (must-have / should-have / nice-to-have).
...

Tech Lead (tech-lead.md) : traduit les stories en tâches techniques, définit l'architecture, fait les choix techniques (Vue 3/TS, structure des composants, conventions), reviewe le travail des devs. Accès lecture/écriture code, Linear, Figma (design system, variables).

---
name: tech-lead
description: Traduit les user stories Linear en tâches techniques, définit l'architecture, review le code des devs. À invoquer pour toute décision d'architecture ou de découpage technique.
tools: Read, Grep, Glob, Bash, Edit, Write, mcp__figma, mcp__linear
---

Tu es le Tech Lead de l'équipe. Stack : Vue 3 + TypeScript (front), Node.js (back).
Avant toute implémentation, tu dois :
1. Lire le ticket Linear associé et ses critères d'acceptation.
2. Traiter les détails de design (couleurs, positions, composants) déjà écrits par l'agent UI/UX comme la source de vérité design, et n'ouvrir Figma toi-même que pour les contraintes techniques/responsive non couvertes.
3. Découper la story en tâches techniques atomiques, une par composant/endpoint.
4. Chercher dans Linear une sous-tâche existante correspondante avant d'en créer une.

Devs (dev-frontend.md, dev-backend.md) : implémentent les tâches assignées, en s'appuyant sur le contexte Figma (composants, tokens) et les specs Linear. Accès code complet, Figma en lecture, Linear pour mettre à jour le statut des tickets.

---
name: dev-frontend
description: Implémente les tâches frontend assignées par le Tech Lead (Vue 3 + TypeScript). À invoquer pour toute tâche de composant UI.
tools: Read, Grep, Glob, Bash, Edit, Write, mcp__linear
---

Tu es développeur frontend. Stack : Vue 3, TypeScript.
Pour chaque tâche reçue :
1. Passe le ticket Linear en "In Progress" avant de commencer.
2. Lis le contexte Linear associé, y compris les détails de design propagés par le Tech Lead depuis l'agent UI/UX.
3. Implémente le composant en respectant les design tokens (pas de couleur en dur).
4. Une fois terminé, passe le ticket en "In Review".

Testeurs (qa.md) : écrivent et exécutent les tests (unitaires, e2e), valident les critères d'acceptation de la story, ouvrent des tickets de bug dans Linear si un écart est détecté. Accès code (lecture + tests), exécution de commandes (Bash), Linear.

---
name: qa
description: Écrit et exécute les tests, valide les critères d'acceptation d'une story, ouvre des bugs Linear si besoin. À invoquer pour toute validation de story.
tools: Read, Grep, Glob, Bash, Edit, mcp__linear
---

Tu es le QA de l'équipe. Pour chaque story à valider :
1. Relis les critères d'acceptation du ticket Linear.
2. Écris les tests correspondants (unitaires et/ou e2e).
3. Exécute-les.
4. En cas d'écart, ouvre un ticket de bug Linear avec une reproduction détaillée, taggé selon la zone concernée (`Frontend`, `Backend`, `Database`, ...).

UI/UX Designer (ui-ux.md) : c'est le rôle le plus particulier, puisque Claude Code ne dessine pas dans Figma à votre place de façon autonome. Mais avec le serveur MCP Figma, il peut lire les maquettes, extraire les composants/variables/design tokens, et même écrire sur le canvas (créer/mettre à jour des frames, composants, styles).

---
name: ui-ux
description: Extrait le contexte design Figma (composants, couleurs, positions, variables) d'une story, et écrit les détails d'implémentation frontend dans les tickets Linear. À invoquer pour tout besoin de contexte design.
tools: Read, Grep, Glob, Edit, Write, mcp__figma, mcp__linear
---

Tu es l'UI/UX Designer de l'équipe. Le design de référence est le fichier Figma fourni pour ce projet. Pour chaque story reçue :
1. Extrais du design Figma les composants, couleurs, positions et variables pertinents pour la story.
2. Écris ces détails dans le ticket Linear correspondant sous un format structuré fixe, un bloc par composant.
3. Capture une image de la frame Figma concernée et attache-la au même ticket Linear.

Connecter les outils externes via MCP​

C'est la brique qui transforme cette équipe d'agents en véritable pipeline produit : sans MCP, vos agents "discutent" du produit ; avec MCP, ils lisent et écrivent dans vos vrais outils.

Figma​

Figma propose un serveur MCP en deux versions : une version distante (recommandée, la plus complète, hébergée par Figma) et une version desktop, réservée à des cas d'usage entreprise spécifiques, qui nécessite l'app Figma ouverte en local.

Pour la version distante, dans Claude Code :

claude mcp add --transport http figma https://mcp.figma.com/mcp

Puis dans une session Claude Code, tapez /mcp, sélectionnez figma, Authenticate, et autorisez l'accès dans le navigateur.

Une fois connecté, vos agents peuvent extraire le contexte d'un frame ou d'une sélection (composants, variables, layout, contenu FigJam), générer du code aligné avec vos composants réels grâce à Code Connect, ou encore écrire directement sur le canvas Figma. C'est pratique pour que le Tech Lead ou le designer synchronisent un prototype codé vers Figma pour revue d'équipe.

Linear​

Linear propose également un serveur MCP officiel, hébergé, avec authentification OAuth, donc pas de token à gérer manuellement :

claude mcp add --transport http linear https://mcp.linear.app/mcp

Puis /mcp dans Claude Code pour déclencher le flow OAuth.

Une fois connecté, vos agents PO/PM/Dev/QA peuvent chercher des tickets, en créer, changer leur statut, commenter, lier des PR, le tout en langage naturel :

"Lis le ticket ENG-142, implémente le correctif, puis passe le ticket en
'In Review' et commente avec la liste des fichiers modifiés."

La facture qu'on ne voit pas venir​

C'est le point qu'on oublie facilement en montant ce genre de squad : chaque serveur MCP connecté injecte la définition de tous ses outils dans le contexte, à chaque tour de conversation, pour chaque agent qui y a accès. Avec Figma, Linear et éventuellement un troisième serveur branchés sur six agents, la facture en tokens grimpe vite, et le modèle met plus de temps à choisir le bon outil quand la liste s'allonge. Je l'ai découvert en connectant tous les serveurs à tous les agents "au cas où", avant de me rendre compte que ça ralentissait tout sans bénéfice réel.

Concrètement : ne connectez un serveur qu'aux agents qui en ont vraiment besoin (un QA n'a rien à faire avec Figma), préférez les versions distantes aux versions locales, et coupez les serveurs inutilisés en cours de session avec /mcp plutôt que de tout laisser tourner en permanence.

Sur le quand et le comment : connectez-vous au moment où l'agent a réellement besoin de lire ou d'écrire dans l'outil externe, pas par réflexe en début de session. Utilisez claude mcp add avec le scope le plus restreint possible (par projet plutôt que global), et privilégiez l'authentification OAuth quand le serveur la propose, plutôt qu'un token statique qui traînera dans une config quelque part.

Le workflow de A à Z​

Voici le déroulé typique pour livrer une fonctionnalité, de l'idée au code testé.

Le PM décrit le besoin en langage naturel ; l'agent PM le formule en epic, vérifie qu'il rentre dans la roadmap, et crée le projet Linear correspondant.

L'agent PO prend le relais pour transformer l'epic en user stories avec critères d'acceptation, les priorise, et les pousse dans Linear.

L'agent UI/UX entre en jeu si un design existe déjà dans Figma : il extrait les composants et variables pertinents pour la story et les rattache au ticket. S'il faut prototyper, il peut générer un premier jet de composant codé puis l'envoyer vers Figma comme point de départ de discussion.

Le Tech Lead lit la story Linear et le contexte Figma, définit l'architecture des composants/endpoints, et découpe le tout en tâches techniques assignées aux subagents devs.

Chaque agent dev récupère sa tâche, lit le contexte Figma et Linear, implémente, ouvre une PR, et met à jour le statut du ticket.

L'agent QA écrit les tests correspondant aux critères d'acceptation, les exécute, et soit valide le ticket soit ouvre un ticket de bug avec repro détaillée.

Le Tech Lead fait une dernière passe de review avant merge, en vérifiant la cohérence avec le design system via Code Connect.

Ce découpage en rôles évite l'écueil classique du "un seul agent qui fait tout dans une seule conversation énorme" : chaque étape tourne dans un contexte propre, ce qui limite la pollution de contexte et améliore la qualité de chaque décision.

CLAUDE.md : la colonne vertébrale partagée​

Tous les agents doivent partager un socle commun de règles projet, posé dans un fichier CLAUDE.md à la racine (la doc officielle sur la mémoire de Claude Code détaille bien le mécanisme). L'équivalent générique porté par AGENTS.md remplit le même rôle :

# Projet : [nom de l'app]

## Stack
Frontend : Vue 3 + TypeScript
Backend : Node.js
Design system : Figma (fichier X, lien Y)
Ticketing : Linear (équipe "Product")

## Règles
- Toute implémentation doit être rattachée à un ticket Linear.
- Ne jamais merger sans review du Tech Lead.
- Respecter les tokens de design extraits de Figma (pas de couleurs en dur).
- Écrire un test pour chaque nouveau composant/endpoint.

Ce fichier est lu par tous les agents en début de session : c'est ce qui garantit la cohérence entre le PO qui écrit une story, le dev qui l'implémente, et le testeur qui la valide.

Un agent chef d'orchestre pour lancer tout le workflow​

À un moment, invoquer manuellement chaque rôle à la suite est devenu fastidieux, alors j'ai crée un dernier subagent qui porte le workflow complet : il reçoit le besoin en langage naturel et enchaîne lui-même les étapes (PM → PO → UI/UX → Tech Lead → Devs → QA), en déléguant chaque tâche au bon agent.

---
name: orchestrator
description: Prend un besoin métier en langage naturel et pilote toute l'équipe (PM, PO, UI/UX, Tech Lead, Devs, QA) jusqu'à la fonctionnalité livrée et testée. À invoquer pour lancer un workflow complet de bout en bout.
tools: Task
---

Tu es le chef d'orchestre de la squad. Pour tout besoin reçu :
1. Délègue à `pm` le cadrage en epic et la création du projet Linear.
2. Délègue à `po` le découpage en user stories avec critères d'acceptation.
3. Délègue à `ui-ux` la récupération ou le prototypage du design Figma associé.
4. Délègue à `tech-lead` le découpage technique et l'architecture.
5. Délègue à chaque `dev-frontend`/`dev-backend` sa tâche assignée.
6. Délègue à `qa` la validation des critères d'acceptation.
7. Fais revalider par `tech-lead` avant de considérer la fonctionnalité livrée.
Ne saute pas d'étape et attends le résultat de chaque agent avant de déléguer la suivante.

Ce rôle ne remplace pas les autres, il se contente de les enchaîner : chaque étape reste exécutée dans le contexte propre de son subagent, l'orchestrateur ne fait que transmettre le résultat d'une étape à la suivante.

Points de vigilance​

Commencez petit : trois ou quatre serveurs MCP (Figma, Linear, GitHub) suffisent largement au départ. Chaque serveur ajoute des outils que le modèle doit évaluer à chaque tour, et au-delà d'une dizaine de serveurs, le choix d'outil se dégrade nettement.

Les Agent Teams restent expérimentales, token-intensives, avec des limites connues sur la reprise de session. Validez d'abord votre workflow avec de simples subagents avant d'y migrer.

Restreignez les permissions par rôle : un agent PO n'a aucune raison d'avoir un accès en écriture au code, un agent QA n'a pas besoin d'écrire dans Figma. Le couple tools/disallowedTools dans le frontmatter de chaque subagent sert exactement à ça.

Le lien Figma reste la méthode la plus fiable pour donner du contexte design à un agent, la sélection active dans l'app desktop décroche trop souvent pour qu'on s'y fie.

Au final, monter une "équipe" d'agents est une combinaison assez terre-à-terre de sous-agents bien scopés (un rôle, un fichier .claude/agents/*.md, des outils restreints, une mission claire) d'un CLAUDE.md qui fait office de contrat d'équipe et de deux ou trois serveurs MCP qui relient vos agents à vos vrais outils de travail.

Ce qui a changé pour moi, c'est autant la vitesse d'exécution que la clarté : chaque agent sait précisément ce qu'il a le droit de faire, et je passe beaucoup moins de temps à réexpliquer le contexte à chaque nouvelle tâche.

Retour sur notre visite à DevLille 2026 : les conférences qui nous ont marqués, celles qu'on a données, nos coups de cœur... Revivez à travers les yeux des talents de zatsit la conférence incontournable du nord de la France !

DevLille, c'est quoi ?​

C'est chaque année le rendez-vous à ne pas manquer pour les passionnés de tech : Dev, Ops, Architecte... L'occasion de croiser d'anciens ou futurs collègues, de découvrir ou redécouvrir des technos, parfois sous un angle surprenant, pourquoi pas déroutant même. Nous espérons que vous avez déjà vécu une édition, si ce n'est pas le cas, il faudra remédier à ça l'année prochaine.

Par cet article, nous tenons à réitérer nos remerciements à l'équipe organisatrice. Perte de sponsor, mouvement social (compréhensible, bien sûr, mais par nature imprévisible), inflation... autant d'obstacles à franchir pour garantir une conférence sur deux jours sans accrocs. Comme les meilleurs numéros d'acrobatie, si on ne ressent pas la difficulté, c'est que c'est bien maîtrisé !

Plongez avec nous dans les conférences qui nous ont marqués, mais avant petit clin d'œil à notre participation.

zatsit à DevLille​

Tous les ans, notre collectif se retrouve pour participer à DevLille. Comme chaque mois, nous profitons d'un zatsday pour apprendre ensemble et passer un bon moment. Cette année, plus que spectateur, nous étions aussi speaker ! 3 interventions au programme :

• Le CDC pour ne pas DCD par Ludovic et Quentin : un REX sur un produit legacy qui produisait de la donnée obsolète ou manquante, sauvé en adoptant le Change Data Capture. Avec des démos autour de Debezium et Kafka, des échanges sur base d'architecture event-driven et même des cadeaux à gagner, si vous aviez compté le nombre d'acronymes lors du talk.

D'ailleurs, si vous voulez comprendre comment fonctionne le WAL sous Postgres, il y a aussi eu un talk à DevLille à ce sujet :)

• Contract-First : reprends le contrôle de tes API avec des outils qui changent la vie par Emmanuel : un workflow Contract-First complet où le contrat OpenAPI devient source de vérité (mock avec Microcks, lint avec Vacuum, rétrocompat avec Openapi-diff, tests...), le tout outillé par des agents IA (Claude Code, Gemini CLI) via des skills publiés sur skills.sh.

• EcoScore A ou E : où se situe vraiment votre API ? par Emmanuel : comment mesurer l'éco-conception d'une API via deux référentiels open source complémentaires, API Green Score et EROOM de Boavizta (maturité globale), avec à la clé un outil lui-même éco-conçu.

Ces 3 talks ne sont pas anodins, ils reflètent l'expertise et les moteurs des talents de zatsit : l'architecture technique et l'éco-conception. Ces deux thématiques, entre autres, animent nos zatsdays et notre quotidien !

Les conférences qui nous ont marqués​

"Choisir, c'est renoncer", c'est déjà assez difficile le jour J de choisir entre les 3 tracks, alors la sélection qui suit l'est encore plus.

Handicap invisible : l’accessibilité commence dans les réunions (et l'IA peut aider)​

Vu par Emmanuel

Par Anaïs Moulin

Anaïs nous le confie elle-même, elle a un handicap invisible, elle est sourde de l'oreille droite. C'est donc plus facile de lui parler du côté gauche lors de la pause café, mais c'est une autre histoire lors des réunions physiques et à distance.

Le chiffre de la photo ci-dessus est énorme, 9 millions de Français ont un handicap invisible, parmi ces handicaps, les 6 grandes familles les plus représentées :

• Maladies chroniques invalidantes : sclérose en plaques, fibromyalgie, endométriose, diabète... La catégorie la plus large.
• Troubles sensoriels : surdité, malentendance (le cas d'Anaïs Moulin), déficiences visuelles partielles.
• Troubles psychiques : dépression, troubles anxieux, bipolarité, schizophrénie.
• Troubles neurodéveloppementaux : TDAH, troubles du spectre autistique, souvent diagnostiqués tard.
• Troubles « dys » : dyslexie, dyspraxie, dyscalculie, avec un impact direct sur la lecture et le traitement de l'info à l'oral ou l'écrit.
• Troubles cognitifs : mémoire, attention, difficultés à planifier...

Il y a donc une forte probabilité pour que vous ou l'une des personnes de votre équipe ait un handicap de cette liste. Ces personnes font déjà énormément d'efforts pour aménager comme elles peuvent leurs conditions de travail afin de limiter les difficultés qui en résultent. Elles vont, par exemple, s'équiper d'un casque à réduction de bruit, d'un écran spécifique, d'un siège ergonomique très cher, d'un bureau assis/debout onéreux aussi...

Posons nous la question : "Que nous soyons concernés ou pas par un handicap, que pouvons-nous faire pour nos collègues ?"

Déjà, Anaïs nous rappelle que ce n'est pas "écrit sur le front" et que bon nombre de personnes n'osent pas en parler, alors partons du principe que statistiquement dans vos meetings par exemple, au moins une personne va devoir faire plus d'efforts que les autres. Les exemples concrets pour lesquels il est facile d'avoir un impact positif sont les "réunions" :

• Allumer sa caméra : c'est plus facile de voir des réactions, détecter qui parle et même potentiellement lire sur les lèvres.
• Promouvoir dans l'entreprise des solutions intégrées de génération de sous-titres.
• Prévoir un ordre du jour : handicap ou pas, c'est pénible d'avoir une réunion sans ordre du jour préalable.
• Préparer sa réunion : produire des documents en amont dont tout le monde peut prendre connaissance et prévoir un livrable en fin de réunion.

Honnêtement ça relève plus du bon sens et de l'organisation intelligente. Fini les "Point projet X" dans lesquels on doit improviser sur des questions hasardeuses, ne rien produire et prévoir la "Suite du point projet X". C'est une liste que j'essaie d'exiger systématiquement dans mes expériences professionnelles, mais vraiment pas facile à imposer. À croire qu'on aime la réunionite exclusive et peu productive.

Alors, pour la prochaine que vous organisez, essayez de prendre le bon réflexe.

DevGreenOps : Passer du sprint à l'endurance énergétique avec Decathlon x Greenspector​

Vu par Emmanuel

par Nathalie Otte, Olivier Philippot et Ludovic Roland.

Decathlon fait partie des enseignes préférées des Français, ils font beaucoup pour le sport et ont socialement une place importante. C'est naturellement qu'ils ont donc enclenché une démarche responsable aussi dans le numérique comme nous le rappelle Nathalie (GreenIT Leader). Dans le talk zatsit qui parlait d'Écoscore, nous avons fait référence au REX de Decathlon que nous vous conseillons donc aussi ici : https://youtu.be/3Xtvw8LdYWg?si=YF3m0gT9uNP9eXI9

Dans ce talk du DevLille, nous apprenons comment l'application mobile ecommerce de Decathlon est maintenant auditée par Greenspector. Greenspector est une solution SaaS française qui mesure la sobriété et la performance des services numériques (applications mobiles, sites web, IoT...) via des sondes d'énergie réelles sur banc de tests physiques. Elle convertit ces mesures en Écoscore et en impacts environnementaux, s'intègre dans une chaîne CI/CD : le DevGreenOps.

Concrètement, l'équipe réalise des tests sur devices physiques pour les builds destinés aux stores d'app. En production, pour être fidèle à l'expérience utilisateur, des scénarios réels sont déroulés en effectuant des mesures sur le CPU, les échanges réseaux... afin de révéler l'utilisation batterie entre autres. La prochaine étape est de pouvoir réaliser ces tests de bout en bout pour mesurer à la fois l'efficacité frontend, mais aussi côté back.

Vivement qu'on puisse voir dans un prochain talk les résultats complets !

Sculpter le bruit : Retour d'expérience sur la génération de textures sonores​

Vu par Emmanuel

par Sébastien Ferrer

Je ne savais pas trop à quoi m'attendre avec ce talk, et c'est précisément ce qui m'a plu : ça change radicalement de la tech qu'on voit défiler toute la journée, mais pourtant c'est de la tech ! Pas de framework, pas de pipeline, pas de cloud, plutôt de l'analyse de signal et un peu de maths. Le point de départ : Sébastien vit avec un acouphène permanent. Plutôt que de le subir, il a cherché à comprendre comment le son pouvait masquer ou apaiser ces fréquences parasites. Et de fil en aiguille, il s'est retrouvé à coder ses propres bruits.

Là où ça devient malin, c'est qu'on parle de quelques lignes de code, selon lui "l'algo le plus simple qu'il ait jamais écrit". Pas de deep learning, pas de modèle entraîné sur trois data centers. De la distribution aléatoire, des filtres, un peu de manipulation de signal, et l'algorithme pour générer du bruit rose proprement. Du chaos mathématique transformé en confort auditif, et on voyait le son devenir image à l'écran, le spectre se dessiner sous nos yeux. On a même vu le logo DEVLILLE 2026 et ça c'était fun, effet démo garanti ! Les pièces du puzzle se sont mises en place. Tous ces bruits "colorés" qu'on croise sans jamais y réfléchir : Le bruit blanc, agressif, sifflant, c'est exactement la neige sur les vieux téléviseurs cathodiques (pour les plus anciens dans la salle).

Le bruit rose, plus doux, plus équilibré, c'est celui qui peuple les playlists "sommeil" et "concentration" de Spotify et Deezer. Si tu t'es déjà demandé pourquoi ces playlists marchent mieux que le blanc pour dormir, c'est une histoire de répartition d'énergie par octave : l'oreille humaine le perçoit comme plus naturel, plus proche de la pluie que du sifflement.

Le bruit brun (ou rouge, ou brownien, c'est le même), encore plus grave, ce grondement profond (comme un orage nous dit Sébastien) façon cascade ou ressac, une ambiance de plage, on sent le sable sous nos pieds. Bref, un talk qui ne servira peut-être jamais directement dans mon job, et c'est très bien comme ça.

Parfois il faut juste une conf qui te fait regarder ton vieux poste cathodique d'un autre œil, qui explique ta playlist de concentration...

Qui a marqué le plus de buts ? construire un agent IA qui interroge des données en langage naturel​

Vu par Ludovic

par Mazlum Tosun

Mazlum, habitué du DevLille, présente un sujet concret, sur la mise en place d'un agent IA permettant d'interroger les données de la coupe du monde du Qatar.

Contrairement à la majorité des talks, celui-ci présente les technologies, l'architecture et le workflow de CI utilisés pour en venir à une démonstration de l'intégration de la stack, d'abord en local, puis déployée sur GCP dans Cloud Run.

L'application s'articule donc autour de 4 composants clés :

• Le front en Next qui intègre CopilotKit, pour l'intégration IA
• Agent Development Kit (ADK) côté backend, pour le framework permettant d'orchestrer les agents
• Vertex AI côté Google, permettant de fournir un LLM pour converser (Gemini 2.5 Flash) ici
• BigQuery et son MCP pour la source de donnée (données de la CDM au Qatar)

Côté CI, du classique sur GCP pour orchestrer le déploiement vers Cloud Run :

En 45 minutes, Mazlum a donc permis à l'auditoire de comprendre comment créer sa première plateforme conversationnelle, sur base d'exemples, de schémas et de démonstrations. C'est ce qu'on attend, quand on participe à une conférence : repartir avec des choses à actionner !

Le clou du spectacle ? La possibilité de s'amuser avec cette stack exclusivement en local, sans consommer de tokens IA :

On adore !

Si vous voulez aller plus loin :

• Les slides
• Le code source du projet

Déployer souvent, stresser moins : feature flags en prod critique​

Vu par Quentin et Ludovic

par Marion Chineaud et Elise Souvannavong

Dans ce talk du DevLille, Marion et Elise nous embarquent dans leur méthodologie pour livrer plus vite, sans friction entre la tech' et le métier. Elles y détaillent quelques techniques pour mitiger les risques d'un déploiement et pour permettre aux équipes en charge du métier de tester leurs idées sans impacter le delivery et les utilisateurs.

Tout le monde sera d'accord pour dire que pour déployer souvent, il faut d'abord découper et merger fréquemment son code. Et ce que suggèrent Marion et Elise, c'est de séparer l'action de merger et de déployer. C'est vrai que bien souvent, on attend que tout soit prêt à être déployé pour être mergé et l'on entre dans des tunnels. Et pour éviter d'impacter les utilisateurs avec des demi-features, elles suggèrent d'utiliser des release flags : des booléens, stockés de préférence séparément de la codebase, pour activer ou désactiver des features.

Dans une seconde partie du talk, Elise et Marion évoquent la volonté de l'équipe métier de pouvoir piloter l'application avec des flags, afin de réaliser des tests. On parle alors d'A/B testing (tests de variants d'une feature afin de choisir celle qui correspond le mieux aux utilisateurs), shadow mode (déploiement d'un service critique en parallèle de l'application afin de tester son comportement en conditions réelles) ou de canary release (release différenciée suivant la typologie d'utilisateurs afin de recueillir des feedbacks des bêta-testeurs avant une mise en production généralisée). Des concepts intéressants, à mettre en pratique si le besoin se fait ressentir dans les équipes !

Un warning tout de même : les flags c'est beau mais ne pas oublier le clean après les releases !

Le mot de la fin : faire d'une release un non-évènement, je pense que c'est ce vers quoi tout développeur/toute développeuse veut aller.

IA et bonnes pratiques: Nom de Zeus, on savait déjà tout !​

Vu par Quentin et Ludovic

par Nathan Castelain

Dès le début du talk, nous sommes embarqués dans l'univers de Retour vers le Futur. Le pitch ? Nathan arrive en 2026, au moment où l'IA est prédominante dans le quotidien des développeurs. Le Doc est lui même une IA qui dicte les bonnes pratiques en termes de prompting et d'utilisation de l'IA agentique. Mais, Nathan vient de 2024, une époque où l'IA pour les développeurs se limitait à poser des questions dans un chat et copier éventuellement le snippet de code, bien loin des pratiques actuelles donc !

Le but de ce talk est de déconstruire les concepts du moment autour de l'IA agentique (Context Engineering, Prompt Engineering, etc.) et de les croiser avec des concepts et pratiques de développement existants depuis quelques décennies, comme l'agilité et son manifeste, le Behavior Driven Design, le Domain Driven Design, ...

Un talk qui invite à prendre du recul sur l'utilisation de l'IA et à se rappeler que, finalement, on n'a rien révolutionné en termes de concepts. Le Context Engineering n'est qu'un nouveau nom pour des réflexes qu'on connaît bien : découper, donner du contexte métier, structurer l'intention avant de produire. La vraie nouveauté, elle, est ailleurs : on écrit (ou plutôt on fait écrire) du code plus rapidement. Reste à savoir si nos pratiques craft suivront le rythme.

Conclusion​

On repart avec deux sentiments :

• On a fait notre possible pour proposer des talks à notre image : de l'architecture technique, de la plomberie technique, pragmatique
• et même de l'éco-conception, parce que c'est une urgence !
• On a adoré croiser nos collègues, avoir de l'inspiration et prendre le pouls de la tech lilloise.

Comme chaque année, ça nous semble naturel, chez zatsit d'emmener tout le collectif prendre une bonne bulle d'air tech et quand on voit que certains pairs ne sont jamais allés à une conférence, c'est triste. Chacun dans notre métier doit produire un travail de veille personnel, c'est sûr, mais l'entreprise a le devoir de former son collectif de l'emmener voir d'autres horizons, même si ce n'est qu'à quelques kilomètres, le savoir ne vaut que s'il est partagé !

La FOSDEM (Free and Open Source Software Developers' European Meeting) est un événement annuel qui rassemble les acteurs et actrices de l'open source du monde entier. Pour la 3e année consécutive, votre serviteur a pris sur son temps libre pour se rendre à Bruxelles et assister à une douzaine de conférences sur les plus de 1000 qui se tenaient ce week-end du 1er et 2 février 2026. Voici un condensé de ce qui a retenu son attention.

La FOSDEM : du plus utilitaire au plus expérimental​

La FOSDEM est à l'image de l'open source : c'est un événement gratuit qui tient grâce à l'engagement de certains acteurs privés (comme Google), de fondations liées à l'open source (comme Red Hat), de partenaires publics (comme l'Université Libre de Bruxelles) et surtout de centaines de bénévoles qui organisent l'événement, accueillent les participants, et surtout créent le contenu des plus de 1000 conférences qui se tiennent pendant ces deux jours.

Dans ce contenu, on trouve de tout : des conférences très techniques sur des sujets de niche, des conférences plus généralistes sur les tendances du moment. On peut autant ressortir d'une conférence en se disant « j'ai hâte d'utiliser ça dans mon projet »¹ que « je n'ai pas compris la moitié de ce qui a été dit, mais c'était fascinant » (en passant par de franches tranches de rire en écoutant les mésaventures d'un mainteneur open source face à des utilisateurs et utilisatrices pas toujours très compréhensif·ve·s).

Un peu de Java, des containers et des nouveautés dans l'OpenID​

Au rang des conférences que je vais définitivement vouloir réutiliser dans mes projets, j'ai retenu celles-ci :

• Java Memory Management in Containers
• Reducing container images size with eBPF & Podman
• An Introduction to the OpenID Shared Signals Framework

JVM in Containers​

Forcément, on a tous nos biais : en tant que développeur backend Java, la gestion de mémoire et la taille de mes conteneurs sont des problématiques auxquelles je suis confronté dans mon travail quotidien. Et même si j'utilisais déjà quelques options de la JVM pour tweaker la gestion de mémoire dans mes containers, j'ai appris pas mal de choses. Par exemple, saviez-vous que les différents distributeurs de Java livrent des versions de l'OpenJDK avec des gestions de mémoire différentes ? Ainsi, le Maximum Heap Size par défaut de Java 21 est 25%, mais la version de Red Hat, optimisée pour le déploiement en container, est livrée avec un Maximum Heap Size par défaut à 85% ! Et c'est logique : quand on tourne dans un container entièrement dédié à notre JVM, on peut récupérer plus d'espace mémoire.

eBPF pour alléger ses containers 🌱​

J'ai aussi suivi avec beaucoup d'attention Axel Stefanini (de chez Red Hat justement) qui nous a présenté comment, grâce à eBPF, il a pu monitorer ses déploiements et identifier tout ce qui était inutile dans ses containers, pour ensuite réduire drastiquement la taille de ses images (une approche similaire aux images distroless dont on parle de plus en plus ces dernières années). Plus qu'une question de performance, c'est aussi une question d'empreinte carbone : plus les images sont légères, moins elles consomment de ressources pour être transférées et stockées. Et chez zatsit, ce genre d'approche nous parle beaucoup !

OpenID Shared Signals Framework​

Le dimanche, j'ai sacrifié ma grasse matinée pour assister à la conférence de Thomas Darimont sur une nouvelle fonctionnalité du standard OpenID : le Shared Signals Framework.

Cette nouvelle fonctionnalité permet de partager des signaux entre fournisseurs d'identité et clients. On est tous désormais plus ou moins familiers avec l'utilisation des fournisseurs d'identité comme Keycloak, qui nous permettent de nous identifier sur plusieurs ressources grâce à un fournisseur d'identité unique. Mais voilà : aujourd'hui, notre fournisseur d'identité ne peut pas communiquer à son initiative avec les clients qui l'utilisent. C'est ce que viennent permettre les Shared Signals.

Si par exemple vous avez utilisé Google pour vous connecter à votre compte GitHub, ainsi qu'à un service de streaming, et puis bien sûr à votre client mail, et que malheureusement quelqu'un a deviné votre mot de passe (il faut dire que « adminPassword123 » ce n'était pas très compliqué) : Aujourd'hui, Google se rendra probablement compte que quelque chose n'est pas clair (en fonction de l'origine de la connexion par exemple), mais il ne sera pas en mesure d'avertir les autres clients que la sécurité de votre compte a été compromise. Demain, grâce aux Shared Signals, Google pourra envoyer un signal à tous les clients qui l'utilisent comme fournisseur d'identité pour les avertir que votre compte a été compromis, et ainsi permettre à ces clients de révoquer vos sessions actives ou de vous demander de changer votre mot de passe. Que ce soit pour la sécurité en entreprise ou pour nos utilisations du quotidien, c'est une fonctionnalité qui peut faire une grande différence et qui deviendra très certainement un standard dans les années qui viennent.

Linux on mobile et reverse engineering Spotify​

La FOSDEM, c'est aussi l'occasion de découvrir des sujets plus expérimentaux. En tant qu'aficionado de custom ROM Android et pourfendeur de l'obsolescence programmée, j'ai été très intéressé par la conférence d'Affe Null sur son portage de Linux mainline (c'est-à-dire du kernel Linux sans modification) sur mobile. On est loin d'avoir un mobile utilisable au quotidien pour l'instant, mais c'est toujours très inspirant de voir des passionné·e·s (surtout si jeunes !) se lancer dans un reverse engineering complexe et l'écriture de drivers à la main, juste parce qu'ils étaient curieux de savoir comment ça marche.

Dans la catégorie "projets expérimentaux", la conférence de devgianlu, Reverse Engineering the World's Largest Music Streaming Platform m'a aussi marqué (comment ne pas l'être quand le conférencier commence par ce disclaimer : « If there's someone from Spotify in the audience, please don't sue me. Let's talk first »). Plus qu'une lubie de passionné, ce genre de projet est aussi la ligne de front de la lutte contre les pratiques anti-consommateurs de certaines grandes entreprises. Parce qu'être en maîtrise de son matériel et de ses logiciels, c'est aussi être en maîtrise de ses données et de sa vie privée.

Forcément, de l'IA​

Impossible de passer à côté de la révolution de l'IA générative à la FOSDEM. Mais au-delà des alternatives open source aux LLM bien connus, la FOSDEM est aussi l'occasion d'aborder le sujet sous un angle qu'on n'entend pas assez dans nos métiers : What do we mean when we say Sovereign AI? par Katharine Jarmul nous a offert une réflexion nécessaire sur la dépendance de nos entreprises et de nos États à des entreprises étrangères, notamment états-uniennes, pour l'accès à des modèles d'IA générative.

Face aux changements géopolitiques et aux renversements d'alliances de ces derniers mois, il est plus que jamais nécessaire de se poser la question de la souveraineté numérique et de l'impact que cela peut avoir sur nos entreprises, nos données et notre vie privée. Il faut aussi sortir de la croyance que seules les USA seraient capables de faire de l'IA : il existe des alternatives européennes, et même françaises, qui sont à la pointe de la technologie et qui méritent d'être soutenues.

Grâce à Effie Mouzeli et sa conférence Running Wikipedia on Bare Metal, Open Source, and a Healthy Dose of Caching, j'ai aussi appris que l'IA menace directement la pérennité de Wikipédia. Non pas (seulement) parce qu'elle se nourrit gratuitement du travail de tous les contributeurs et contributrices de Wikipédia pour s'entraîner et recracher ce savoir sans jamais rien donner en retour, mais surtout parce que les bots IA et les outils de scraping qui assaillent continuellement Wikipédia font exploser le trafic et ses coûts d'infrastructure... encore une fois, sans jamais rien donner en retour.

Autant de rappels à l'importance de soutenir les projets open source et à réfléchir à notre usage de l'IA. Ne soyons pas des parasites, soyons des contributeurs et contributrices, des utilisateurs et utilisatrices responsables, et des défenseurs et défenseuses de l'open source !

Conclusion​

Cette édition 2026 de la FOSDEM a encore une fois confirmé que l'open source est bien vivant et continue d'innover sur tous les fronts. Plus qu'un simple événement technique, la FOSDEM nous rappelle que derrière chaque ligne de code se cache une communauté engagée pour un numérique plus libre, plus transparent et plus éthique.

Rendez-vous l'année prochaine pour découvrir les prochaines innovations de l'écosystème open source !

L'eau, c'est la vie​

C'est bien connu : l'eau c'est la vie, elle est majoritaire à la surface de notre "planète bleue". Dans nos contrées, nous y avons accès aussi facilement qu'en tournant un robinet et pourtant elle est plus que jamais souillée, pompée à tout va et tout simplement gaspillée.

Le numérique, comme tous les secteurs économiques, n'échappe pas à cette consommation déraisonnée. Le plus souvent, quand on pense datacenter on pense électricité, et c'est pourquoi on ne les associe rarement à l'eau. C'est à la fois un peu plus compliqué que ça, mais simple à comprendre.

Humain ou moteur, l’eau garde la fraîcheur !​

Dans notre quotidien, on se rend facilement compte de l'intérêt de l'eau. Quelques minutes en plein soleil, ou pendant votre séance de sport, on remarque vite les effets de la transpiration : de l'eau est "produite" sur notre peau et cette eau en s'évaporant va absorber de l'énergie thermique et donc "réduire" la température.

C'est la même chose pour nos bons vieux moteurs thermiques de voiture, dans lesquels un liquide va circuler, s'échauffer en "récupérant" de la chaleur qui va se dissiper au travers d'un radiateur.

Là, vous commencez bien à visualiser l'intérêt d'utiliser l'eau pour refroidir tout système. Ça coule de source et vous ne m'avez pas attendu pour comprendre ça, mais un petit rappel s'imposait quand même.

Un datacenter ça a soif​

Vous le constatez quand vous faites travailler votre laptop, ça chauffe sous les doigts et parfois le ventilateur se fait entendre, mais cette dissipation par air a ses limites. Peut-être faisiez-vous partie de ces bidouilleurs qui faisaient du "watercooling" dans des bécanes montées à la main, avec amour pour programmer ou jouer.

Alors, imaginez la chaleur à l'échelle d'un datacenter. Pour rester opérationnels, ils ont donc besoin de systèmes de refroidissement efficaces. Et beaucoup de ces systèmes (tours d’évaporation, échangeurs eau/air, évaporateurs adiabatiques) utilisent de l’eau.

Encore plus depuis l’explosion des projets "hyperscale" pour l’IA, la question de la consommation d’eau est sortie des rapports techniques pour rejoindre les débats publics. Parlons un peu chiffres.

• Certains datacenters peuvent consommer jusqu'à 5 millions de litres d'eau par jour, soit l'équivalent de la consommation d'une ville de 30 000 habitants.
• "In 2023, Meta consumed 813 million gallons of water globally (3.1 billion liters) — 95% of which, 776 million gallons (2.9 billion liters), was used by data centers. Source
• En Europe, cet autre rapport nous parle de 43,2 milliards de litres d’eau consommés annuellement.
• Ou encore, selon un rapport du Berkeley Lab sur l'utilisation de l'énergie aux États-Unis, cette tendance ne fait que croître.

• Avec 2,5 millions de litres par piscines olympiques, on pourrait en faire nager des championnes et des champions !

Certaines études ne sont pas aussi catégoriques dans les chiffres, les méthodes de comptage diffèrent parfois, certaines prennent en compte la consommation directe (eau prélevée et évaporée ou rejetée par le datacenter lui-même) et indirecte (eau utilisée pour produire l’électricité qui alimente ces mêmes centres, par exemple l'eau évaporée dans des centrales thermiques ou hydroélectriques).

En tout cas les échelles sont là et on note surtout que la tendance est à la hausse.

Comme si ça ne suffisait pas, saviez-vous que près de 40 % de l’énergie consommée par certains datacenters vient de son système de refroidissement... Source

Comment ça marche ?​

Concrètement, quels sont les moyens de refroidissement d'un datacenter et comment fonctionnent-t-ils ?

Par air​

Sans rentrer dans des détails trop complexes, le refroidissement par air est la méthode la plus courante, même si ce n'est pas la plus efficace. Il consiste à faire circuler de l'air frais.

Les CRAC (Computer Room Air Conditioning) fonctionnent comme la climatisation domestique ou en automobile et nécessitent un compresseur et un liquide réfrigérant (pour faire simple encore une fois).

Les CRAH (Computer Room Air Handler) utilisent de l’eau glacée fournie par un refroidisseur central pour refroidir l’air via un échangeur thermique, avant de le redistribuer dans la salle des serveurs. (Vous noterez qu'on commence déjà à consommer de l'eau avec cette dernière technique).

Par eau​

Le "liquid cooling" va donc faire circuler du liquide au plus près des composants pour "absorber" la chaleur. On distingue des sous-catégories comme in-rack (à l’intérieur des baies), direct-to-chip (refroidissement directement aux processeurs) et immersion cooling (serveurs plongés dans un fluide). Système de refroidissement par évaporation. Source : https://www.energy.gov/femp/cooling-water-efficiency-opportunities-federal-data-centers

Pour l'immersion, on vient donc installer des équipements directement dans l'eau, on ne la pompe pas à un endroit pour l'acheminer à un autre.

Vous vous souvenez peut-être du projet "Natick" de Microsoft et son cylindre de 12 mètres embarquant plus de 800 serveurs au large de l'Écosse. L'expérimentation devait permettre aussi de réaliser des batteries de tests et de mesures et non uniquement de refroidir un datacenter. Elle n'a pas été développée à l'échelle pour Microsoft.

En revanche, la Chine a de son côté lancé plusieurs projets, dont un inauguré en ce mois d'octobre. Une structure immergée de 1 300 tonnes pour héberger des services numériques. Ce centre utilise l’eau de mer pour refroidir les serveurs, ce qui réduit fortement la consommation d’énergie liée donc à la climatisation. Il s’agit d’une étape stratégique dans la volonté chinoise d’expérimenter des infrastructures numériques plus durables et innovantes. La réduction d'énergie destinée au refroidissement est à contrebalancer avec les efforts fournis pour une telle structure et ses effets sur l'écosystème local.

Face aux besoins croissants en eau, les géants du numérique déploient des trésors d'ingéniosité... en communication (mais pas que).

On nous parle de "water positivity", de "compensation hydrique", de "WUE" (Water Usage Effectiveness). Des termes bien techniques pour noyer le poisson, si vous me permettez l'expression. Dans cet article, on apprend qu'Amazon finance des projets de restitution et de gestion durable de l'eau dans les pays où elle installe de nouveaux datacenters. Des nouveaux pays de destination qui ne sont pas forcément connus pour être les plus excédentaires en eau, comble de l'ironie. Il y a du positif localement, mais on est en droit de s'interroger sur la transparence dans les calculs, sur le suivi à long terme que requiert ce genre d'installations... Affaire à suivre donc.

Mesurer pour mieux gérer : le rôle du WUE​

La filière tech utilise aussi la métrique WUE (Water Usage Effectiveness) — développée par The Green Grid — pour comparer l’efficacité hydrique des datacenters (litres d’eau consommés par kWh IT ou par unité d’énergie IT). WUE aide à normaliser et à comparer, mais beaucoup d’opérateurs ne publient pas ces métriques et les définitions (direct vs indirect) varient. D’où une demande croissante pour des obligations de reporting plus strictes (réglementaires et de marché).

La réalité, c'est que l'explosion de l'intelligence artificielle (telle que designée aujourd'hui) et de nos usages numériques ne fait qu'aggraver la situation. Les promesses de "datacenters verts" qui réutilisent la chaleur pour chauffer des piscines ou des logements ne sont pas faciles à mettre en œuvre (comme à l'université d'Oldenburg où le datacenter réchauffe des bâtiments et la piscine). C'est aussi la promesse faite pendant les 15 prochaines années du datacenter Equinix PA10 qui transférera le surplus de chaleur à la ZAC de la Plaine Saulnier et au Centre aquatique olympique".

Nul doute que nous continuerons à faire des progrès dans la réutilisation de l'eau ou dans l'efficacité de sa consommation, mais ça ne s'attaque pas au fond du problème de notre soif croissante en puissance de calcul.

Vous l'aurez compris, derrière la promesse d'un "cloud immatériel" se cache un dédale de tuyau, de pompes et de circuits bien réels. À l'heure où tout le monde propose de l'IA gourmande dans ses produits numériques, où le moindre objet est connecté, collecte de la donnée pour la traiter ou simplement la collecter... Il est difficile d'imaginer que nous arriverons à économiser la deuxième ressource la plus importante après l'oxygène pour la majorité des êtres qui peuplent notre grande bleue.

Pourtant, tout n’est pas perdu. De la conception de puces moins énergivores à la relocalisation des serveurs dans des zones plus froides, des ingénieurs et chercheurs s’efforcent d’inventer un numérique plus sobre, plus conscient de ses limites.

L’espoir ne réside peut-être pas dans la promesse d’un datacenter "vert", mais dans notre capacité collective à réapprendre la mesure, à reconnaître que chaque requête, chaque clic, chaque flux vidéo a un coût réel.

Vous avez appris à fermer le robinet quand vous vous brossez les dents, à réduire votre temps de douche, à arroser le potager le soir en plein été... vous penserez peut-être aussi à l'eau maintenant en consommant des services numériques.

Si vous souhaitez consulter plus de sources pour apporter de l'eau à votre moulin, consultez ces pages :

• https://www.eesi.org/articles/view/data-center-energy-needs-are-upending-power-grids-and-threatening-the-climate
• https://www.researchgate.net/figure/Analysis-of-power-consumption-proportionality-in-data-center-8-24_fig4_355862079
• https://bonpote.com/intelligence-artificielle-le-vrai-cout-environnemental-de-la-course-a-lia/#La_consommation_deau
• Amazon says it’s going ‘water positive’ — but there’s a problem
• Data Centers and Water Consumption
• Data center cooling systems and technologies and how they work
• An introduction to how data centers are cooled
• What is computer room air conditioning (CRAC)? CRAC vs. CRAH unit differences?
• Microsoft abandonne son projet de datacenter sous-marin
• China Opens First-Ever Underwater Data Center for Commerce
• Datacenter de l'université Oldenbug

Contexte et introduction​

Avant de commencer à se pencher sur le sujet, il nous faut remettre un peu de contexte. Bien que l'IA existe depuis de nombreuses années, comme le montre, par exemple, l'ordinateur Deep Blue qui a été le premier à vaincre le champion du monde d'échecs en 1997, ou encore Deep Thought qui est le premier ordinateur conçu pour jouer aux échecs, c'est avec l'apparition des chatbots se basant sur les LLM et ouverts au grand public, tel que ChatGPT, en 2022 que l'utilisation de l'IA a explosé. Si avant elle était réservée à des domaines précis et particuliers, aujourd'hui tout le monde peut l'utiliser en quelques clics, que cela soit sur son ordinateur ou son téléphone.

C'est cette ouverture au monde qui a poussé une consommation énergétique importante de l'IA. Et cette consommation ne s'exprime pas uniquement par le nombre de prompts faits par jour, mais aussi par l'énergie utilisée par les datacenters, le réseau, les serveurs lors des entrainements et bien d'autres paramètres encore. Malheureusement, l'ensemble de ces données sont difficilement trouvables et calculables. Pourtant nous savons que l'impact est réel, comme l'admet Google dans son rapport environnemental de 2024 :

In 2023, our total GHG emissions were 14.3 million tCO2e, representing a 13% year-over-year increase and a 48% increase compared to our 2019 target base year.
This result was primarily due to increases in data center energy consumption and supply chain emissions. As we further integrate AI into our products, reducing emissions may be challenging due to increasing energy demands from the greater intensity of AI compute, and the emissions associated with the expected increases in our technical infrastructure investment.

Il est compliqué de connaître exactement l'impact total de ces IA sur l'environnement au travers de sa consommation énergétique. Il y a de nombreux facteurs à prendre en compte et pour cet article, nous avons choisi de nous limiter. Veuillez prendre en compte que les chiffres que nous allons présenter et étudier se basent principalement sur la consommation énergétique des prompts. C'est-à-dire, sur ce qui est dépensé lorsque nous réalisons une demande à ChatGPT ou une IA similaire.

Consommation énergétique d'un prompt​

La consommation énergétique exacte d'un prompt en IA n'est pas connue. Cependant, selon un article de ScienceDirect, une requête ChatGPT consomme environ 2,9 Wh d’électricité, soit presque dix fois plus qu’une simple recherche Google estimée à 0,3 Wh. Nous pouvons aussi citer la Délégation Régionale Académique au Numérique Educatif qui nous informe qu'une requête d’environ 400 tokens sur ChatGPT / GPT-4o mini consomme environ 2 Wh d’électricité, soit plus de 6 fois la consommation d’une recherche Google classique.

Un prompt venant remplacer une simple recherche internet consomme donc 6 à 10 fois l'énergie qui aurait été utilisée si vous l'aviez faite à la main sur Google par exemple.

Mais alors, est-ce que la consommation énergétique de toutes nos actions est multipliée par 10 lorsque nous utilisons l'IA ? Existe-t-il d'autres comparatifs ?

Différentes comparaisons de consommations énergétiques​

En prenant le temps de quelques recherches sur le web (à l'ancienne), il est possible de trouver de nombreuses comparaisons entre la consommation des prompts et d'autres outils ou objets fonctionnant à l'électricité, tout comme le montre l'infographie ci-dessous crée par le média indépendant Basta! à l'aide des informations regroupées par Hugging Face, l'Université de Carnegie Mallon et Futura sciences:

Ces images sont très intéressantes, mais d’un point de vue personnel, elles ne me parlent que peu. C’est pour cela nous allons vous présenter plusieurs cas différents et les comparer à l'énergie consommée par un plein d’essence ou au prix d’un abonnement Netflix.

Pour l'ensemble de ces tests, nous nous baserons sur les informations suivantes :

• Une recherche Google vaut 0,3 Wh
• Les informations fournies par EcoLogits seront notre référence
• Nous arrondirons toujours les résultats à l'entier supérieur
• Notre voiture de tests, une familiale moyenne, a un réservoir de 50 litres
• Un litre d’essence contient l’énergie équivalant à 8,9 kWh d’électricité
• Notre abonnement Netflix est un abonnement Standard à 14,99€/mois
• Nous baserons le prix du kWh à 0.2016€ TTC

En indicatif, nous ajouterons aussi le temps d'une vidéo en streaming dont la consommation énergétique est équivalente à un prompt.

Écrire un mail (170 output tokens)​

Dans cet exemple, nous allons utiliser une demande de génération d'un email simple.

Voici une sortie d'environ 170 tokens :

Objet : Demande de réunion pour suivi du projet

Bonjour Madame Dupont,

J’espère que vous allez bien. Je vous écris afin de convenir d’une réunion pour faire un point d’étape sur l’avancement du projet “Nova”. Nous souhaiterions vous présenter les dernières évolutions ainsi que les prochaines étapes envisagées.

Auriez-vous des disponibilités cette semaine ou en début de semaine prochaine ? Une réunion d’une trentaine de minutes suffirait.

Merci par avance pour votre retour.
Bien cordialement,

Julien Martin
Chef de projet
julien.martin@exemple.com
+33 6 00 00 00 00

Et voici combien de prompts il faudrait effectuer afin d'atteindre les objectifs que nous nous sommes fixés :

Avoir une petite conversation (400 output tokens)​

Cet exemple nous montre les équivalences pour une petite conversation avec notre modèle d'IA favoris.

Comme il est compliqué de vous montrer une conversation complète, voici une sortie d'environ 400 tokens :

Objet : Suivi d’avancement et prochaines étapes du projet Orion

Bonjour à toutes et à tous,

Je vous écris afin de partager un point d’étape sur le projet Orion, dont le développement avance conformément au calendrier prévisionnel établi en début d’année.

À ce jour, les modules suivants sont finalisés :
- Interface de gestion utilisateur
- Système d’authentification renforcée
- Intégration de l’API partenaire

L’équipe développement est actuellement focalisée sur le volet analytique et l’optimisation de la base de données. Ces tâches devraient être complétées d’ici la fin du mois.

Du côté des tests utilisateurs, une première session a eu lieu la semaine dernière. Les retours ont été globalement positifs, notamment sur la fluidité de navigation et la clarté des écrans. Quelques ajustements sont prévus, en particulier sur la vitesse de chargement des rapports.

Voici les prochaines étapes :
- Finalisation des développements restants d’ici le 28 juin
- Phase de tests complète (2 semaines) à partir du 1er juillet
- Livraison de la version stable prévue pour le 15 juillet

Nous organiserons une réunion d’équipe le jeudi 20 juin à 10h pour faire le point ensemble, répondre à vos questions, et ajuster si besoin le plan de charge.

Merci à chacun d’entre vous pour votre implication continue dans ce projet structurant pour l’entreprise. Je reste bien sûr disponible si vous avez des remarques ou demandes spécifiques d’ici là.

Bien cordialement,
Nicolas Petit
Chef de projet – Programme Orion
nicolas.petit@exemple.com
+33 6 01 02 03 04

Et ci-dessous les résultats de nos calculs :

Écrire du code (15 000 output tokens)​

Pour cet exemple, il aurait été souhaitable d'obtenir un code en 15 000 tokens, mais en réalisant la demande aurpès de ChatGTP, voici le résultat qui a été obtenu :

Créer un **code Java de 15 000 tokens exactement** est possible, mais il demande une approche rigoureuse car cela correspond à un **très long fichier source**, d’environ :

* **50 000 à 60 000 caractères** (variable selon le style du code),
* plusieurs **centaines voire milliers de lignes de code**.

---

### ✅ Avant de générer cela, quelques questions importantes :

1. **Souhaites-tu un programme fonctionnel** (par exemple, une application de gestion, un simulateur, etc.) ou est-ce purement une **fresque de code longue** (boucles, classes, commentaires) visant juste à atteindre 15 000 tokens ?

2. As-tu une **préférence de thème** ? Exemples :

   * Gestion d’une bibliothèque
   * Jeu en ligne de commande
   * Système de messagerie
   * Générateur de fractales
   * Algo de machine learning simplifié en Java

3. Comment veux-tu **récupérer le code** ?

   * Le coller ici (ça sera découpé en parties)
   * Le mettre dans un fichier téléchargeable (`.java`) ?

---

### 📌 Exemple de plan pour un code de 15 000 tokens

Pour te donner une idée de structure :

* `Main.java` (point d’entrée)
* `AppManager.java` (gestion générale)
* `User.java`, `Book.java` (classes métier)
* `Database.java` (fausse base de données en mémoire)
* `Utils.java` (fonctions utilitaires)
* Beaucoup de commentaires, logs, tests unitaires en bas, etc.

---

Souhaites-tu que je commence à générer ce code maintenant par blocs (et te donne une estimation exacte de tokens pour chaque partie), ou veux-tu un **fichier Java de 15 000 tokens généré directement** ?

> ⚠️ À noter : ici dans l'interface, les messages sont limités (≈ 4 000 tokens max par message). Donc je devrai **te l’envoyer en plusieurs blocs** ou te proposer un **fichier `.java` complet** à télécharger. Quelle option préfères-tu ?

Mais il est tout de même possible de calculer des équivalences :

Conclusion​

La consommation d'un modèle dépend de beaucoup de choses comme son nombre de paramètres d'entrée, et plus la sortie est grande, plus l'IA consomme d'énergie. Comme nous l'avons dit en introduction, utiliser l'IA ne fait qu'augmenter cette consommation. N'oublions pas non plus que nous n'avons pas pris en compte la consommation énergétique des appels sur le réseau ou encore de l'entrainement des IA.

L'objectif de cet article n'est pas de demander à arrêter d'utiliser l'IA, mais à venir nous sensibiliser sur les impacts énergétiques de cette dernière afin que nous puissions l'utiliser plus intelligemment. Arrêtons de tout lui demander dès que nous faisons face à un problème. Si ce dernier peut être résolu avec une simple recherche Google, privilégions là. Servons-nous de l'IA pour les tâches les plus complexes au lieu de nous demander de synthétiser la documentation d'un programme. À l'inverse, si nous devons utiliser une IA, essayons de prendre le modèle le plus pertinent et spécialisé possible. Ainsi, notre consommation énergétique sera réduite au maximum.

Il est aujourd'hui courant de voir dans son entourage un développeur junior qui pose des questions à l'IA plusieurs fois par jour. Ou encore il y a eu l'apparition du vibe coding où l'IA a une place importante dans l'ensemble du processus de création.

Essayons simplement d'être un peu plus intelligents dans nos utilisations de l'IA et ne laissons pas mourir les forums communautaires comme StackOverflow en posant toujours plus de questions dont la réponse n'existe pas encore !

Cela peut aussi vous intéresser​

Si vous souhaitez approfondir le sujet ou mettre en place des solutions de votre côté, voici des pistes afin d'aller plus loin :

• Utiliser votre assistant IA en local : un autre article de notre blog afin de vous aider à installer une IA en local et l'intégrer dans un IDE
• Impacts de l’intelligence artificielle : risques et opportunités pour l’environnement : avis du Conseil Economique Social et Environnemental sur les impacts de l'IA sur l'environnement
• Quel est l’impact environnemental d’une IA générative ? : un article plus complet sur l'impact environnemental de l'IA
• Comment ChatGPT assoiffe cette population : une vidéo de 10 min par Léo Duff expliquant l'impact de l'utilisation de l'eau pour les datacenters des IA
• compar:IA : un site vous permettant d'analyser le comportement de deux IA et de les comparer. Vous pouvez obtenir des informations sur l'impact environnemental de la requête comme présentée ci-dessous

Ce que nous voulions, c’était faire émerger une autre façon d’entreprendre, dans le numérique.

Une façon plus humaine, plus responsable, plus engagée.

Nous sommes convaincus que la tech peut – et doit – être un levier d’impact positif. Pour nos clients, pour la société, pour l’environnement.

C’est cette conviction qui nous a poussés à faire de zatsit, une entreprise à mission, et à inscrire noir sur blanc notre raison d’être dans nos statuts.

Notre raison d’être

“Engager notre expertise numérique au service de l’impact des entreprises en créant un écosystème partenarial, durable et positif.”

Cette phrase, c’est bien plus qu’une ligne dans un document juridique. C’est notre boussole, notre driver !

Elle nous engage, collectivement, à utiliser notre entreprise et la tech’ pour transformer le monde professionnel de manière durable, inclusive et vertueuse.

Des engagements statutaires concrets

Pour que notre mission prenne vie au quotidien, nous avons défini cinq engagements statutaires forts, gravés dans le marbre, qui structurent notre action :

1. Mettre l’impact environnemental au cœur de nos décisions et de nos actions
   → Cela signifie mesurer, arbitrer, réduire. Que ce soit dans nos déplacements, nos outils, ou nos choix technologiques, l’écologie n’est pas une option.

2. Développer une organisation collaborative
   → Parce que nous croyons que l’intelligence collective dépasse la somme des expertises individuelles, nous construisons un modèle horizontal, avec une gouvernance partagée et transparente, où chacun a sa voix et peut contribuer.

3. Développer des partenariats à impact positif sur la société
   → Nous travaillons avec des partenaires qui partagent notre vision d’une entreprise utile et engagée. Et nous nous engageons en ce sens également (exemple : programme Emergences)

4. Accompagner nos clients à réduire l’impact écologique de leur IT
   → Optimisation des infrastructures, sobriété numérique, conseil responsable : nous mettons notre savoir-faire au service d’un numérique plus responsable et durable.

5. Prendre soin de nos collaborateurs au quotidien
   → Parce que tout commence en interne, par ceux qui font l’entreprise !
   Qualité de vie au travail, écoute, équilibre de vie, transparence : nous cultivons un environnement sain et épanouissant.

Un écosystème partenarial

Être une entreprise à mission, ce n’est pas être seul sur sa montagne. C’est, au contraire, s’inscrire dans un écosystème ouvert, co-construit, aligné.

Chez zatsit, nous fédérons une communauté d’entreprises, de clients, de partenaires et de talents qui croient qu’on peut faire de la tech autrement. Avec exigence, mais sans renoncer à nos valeurs.

Un numérique qui a du sens

Notre métier, c’est le numérique et le service. Mais notre vocation, c’est d’en faire un levier d’impact positif pour la société et la planète.

Nous pensons qu’il est possible – et nécessaire – de réconcilier performance économique, innovation et engagement social et environnemental.

zatsit, c’est notre réponse à cette nécessité.

En résumé

Nous avons créé zatsit comme entreprise à mission pour inscrire nos convictions dans la durée, dans le droit, et dans les faits.
Nous sommes convaincus qu’il peut exister un modèle d’entreprise hybride entre capitalisme et économie sociale/environnementale.

Et aujourd’hui, nous avançons avec cette vision forte !

“Nous sommes des semeurs de graines !”

En tant que développeur·euse·s il n'est pas toujours facile de trouver le temps de maintenir à jour les versions des langages et des frameworks que l'on utilise.

Suivre le rythme des releases n'est pas toujours aisé, et on se retrouve souvent dans ce cercle vicieux : les montées de version mineures ne semblent pas suffisamment intéressantes pour que l'on prenne le temps de les faire. Alors on attend les majeures et les LTS...

Sauf qu'elles sont souvent plus coûteuses en temps et donc plus difficile à intégrer dans nos roadmaps (particulièrement quand elles n'apportent pas de plus value pour nos clients).

Alors on attend. Et généralement, on attend jusqu'à ce que l'on soit obligé de faire cette upgrade (à cause d'une faille de sécurité, de la fin de support, etc...)

Et quand on a attendu bien longtemps, ces montées de version deviennent (parfois) des monstres de complexité, entrainant (parfois) des effets de bords en cascade sur nos dépendances et mobilisant énormément de temps et d'efforts.

Efforts parfois compliqués à justifier face à nos clients :

"Oui, j'ai passé tout le sprint sur la montée de version. Non, il n'y a aucune nouvelle fonctionnalité ou amélioration visible sur le produit. Non, je ne me fous pas de vous, pourquoi vous dites ça ?"

Comment limiter le temps et les efforts que nous demandent ces montées de versions ? Avec OpenRewrite.

OpenRewrite, c'est quoi ?​

Citons la documentation officielle :

OpenRewrite est une solution open source de refactorisation automatisée, permettant aux développeurs d'éliminer efficacement la dette technique au sein de leurs dépôts. Il se compose d'un moteur de refactorisation automatique qui exécute des recettes de refactorisation préemballées et open source pour les migrations de frameworks courantes, les corrections de sécurité et les tâches de cohérence stylistique – réduisant vos efforts de codage de plusieurs heures ou jours à quelques minutes. Bien que l'accent initial ait été mis sur le langage Java, la communauté OpenRewrite ne cesse d'étendre la couverture des langages et des frameworks.

On peut donc retenir que :

1. c'est open source
2. ça refactorise le code en suivant des "recettes"
3. on peut utiliser des recettes open source ou écrire les siennes

Développé au départ autour de l'environnement Java, OpenRewrite est compatible avec Maven et Gradle, permettant d'appliquer les recettes en une ligne de commande.

L'initiative propose également un système de "meta-recette" : des recettes composées de plusieurs recettes, comme celle-ci, pour passer à Spring Boot 3.4 ou encore celle-là pour passer en java 21.

Avec un exemple, c'est plus parlant​

Une rapide recherche sur Github nous a permis de trouver ce dépôt public d'une application de démo pour Spring Boot.

Le dernier commit date d'il y a 3 ans, la version de Spring Boot utilisée est la version 2.6.4 et la version de Java est la version 11.

À l'heure où nous écrivons cet article, la dernière version stable de Spring Boot est la 3.5 et la dernière LTS de Java est la version 21.

Nous avons donc une majeure à passer sur Spring Boot et dix versions sur Java !

Comme il s'agit d'un framework et d'un langage très populaires, on trouve de nombreux guides de migration. Mais grâce à OpenRewrite, nous n'avons pas besoin de regarder une vidéo de plus d'une heure avant de nous mettre à l'ouvrage !

En effet, en appliquant à la suite les commandes Maven fournies dans la recette pour passer à Spring Boot 3.4 ainsi que celle pour passer en java 21, ces deux opérations s'exécutent en quelques secondes.

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-spring:RELEASE -Drewrite.activeRecipes=org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_4 -Drewrite.exportDatatables=true

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-migrate-java:RELEASE -Drewrite.activeRecipes=org.openrewrite.java.migrate.UpgradeToJava21 -Drewrite.exportDatatables=true

Comme notre application de démo n'utilise aucune dépendance en dehors de Spring Boot, on peut directement valider que tout s'est bien passé : les tests passent encore, l'application se lance et fonctionne comme prévu !

<plugin>
    <groupId>org.openrewrite.maven</groupId>
    <artifactId>rewrite-maven-plugin</artifactId>
    <version>6.10.0</version>
    <configuration>
        <exportDatatables>true</exportDatatables>
        <activeRecipes>
            <recipe>org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_4</recipe>
            <recipe>org.openrewrite.java.migrate.UpgradeToJava21</recipe>
        </activeRecipes>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.openrewrite.recipe</groupId>
            <artifactId>rewrite-migrate-java</artifactId>
            <version>3.11.0</version>
        </dependency>
        <dependency>
            <groupId>org.openrewrite.recipe</groupId>
            <artifactId>rewrite-spring</artifactId>
            <version>6.8.2</version>
        </dependency>
    </dependencies>
</plugin>

Certaines recettes nécessitent des paramètres, comme cette recette de changement de nom de package par exemple.

Heureux hasard ! dans notre projet, le fichier SpringdemoApplicationTests.java comporte une erreur de nom de package !

Il suffit d'ajouter à la racine de notre projet un fichier de configuration rewrite.yml comme celui-ci :

---
type: specs.openrewrite.org/v1beta/recipe
name: com.zatsit.ChangePackage
displayName: Rename package name example
recipeList:
  - org.openrewrite.java.ChangePackage:
      oldPackageName: com.sohamkamani.demo
      newPackageName: com.sohamkamani.springdemo

Puis d'ajouter la recette dans la liste à appliquer par le plugin :

<activeRecipes>
    <recipe>org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_4</recipe>
    <recipe>org.openrewrite.java.migrate.UpgradeToJava21</recipe>
    <recipe>com.zatsit.ChangePackage</recipe>
</activeRecipes>

Là encore, un simple mvn rewrite:run et le tour est joué !

What else ?​

Cet exemple simple vous donne un aperçu de la facilité avec laquelle vous pouvez utiliser, combiner, adapter les recettes OpenRewrite por répondre à vos besoins, souvent spécifiques.

Comme précisé ci-dessus, OpenRewrite s'est d'abord développé autour de l'environnement Java, mais s'est aujourd'hui étoffé de milliers de recettes pour des technologies, langages et frameworks aussi divers que variés !

Et si jamais vous ne trouvez pas votre bonheur, comme OpenRewrite est open source, vous pouvez tout à fait écrire votre propre recette, que ce soit pour pouvoir la répliquer facilement sur plusieurs de vos projets, ou pour en faire profiter toute la communauté !

Alors ? Prêt à effectuer vos montées de versions de manière sereine ?

Cet article à propos d'Angular, a pour but de donner un aperçu de la dynamique d'évolution du Framework ces derniers temps, et la direction prise par l'équipe de développement.

En effet, avec des avancées majeures dans les dernières versions via le lancement des composants standalones en expérimental en v14, l'arrivée des Signals en v16 ou encore la nouvelle syntaxe de control flow en v17, Angular progresse bien dans ses objectifs d'améliorer les performances, l'expérience des développeurs, la stabilité et la fiabilité (voir la vidéo "State of Angular" par Minko Gechev, Google Core Team)

Aperçu des changements majeurs depuis 2022​

Standalone components (stable en V15)​

L'un des changements les plus anciens maintenant est l'introduction des standalone components, permettant de se passer des ngModules. Ce changement permet des améliorations de performance avec une mise en place de chargement à la demande (lazy loading) de composant bien plus facilement. La contrepartie principale au quotidien étant de prendre l'automatisme d'importer dans chaque composant les éléments externes utiles (Pipe, Directives, Composants…).

Bien sûr l'équipe d'Angular s'efforce de garder la rétrocompatibilité des versions et fonctionnalités, et il n'est pas prévu que les ngModules soient dépréciés de sitôt.

Depuis la version 19 les composants sont d'ailleurs considérés par défaut comme standalone, et un warning pour les imports inutilisés a été ajouté.

Les signals​

Le présent​

L'autre changement qui a beaucoup fait parler de lui est l'introduction des Signals (stable en v17), un nouveau type de données, mix entre les variables classiques et des observables. Une erreur souvent commise est de penser que les Signals remplacent les Observables, alors qu'ils viennent en combinaison comme l'illustre ce schéma issu de cet article d'Angular Space "Q14: Signals, Observables, Promises - tell me all about differences and when to use which" :

Je vois personnellement les Signals comme des variables réactives, permettant de gérer l'état d'un composant, tout en optimisant la détection de changement en étant compatible avec la ChangeDetectionStrategy OnPush et Angular sans zone.js. Voici ici un rappel sur la manière dont Angular gère cela, notamment avec les signals.

L'écosystème des Signals s'est étoffé dans la version 19 avec les input/output/model de composant remplaçant les @Input, @Output. Et aussi les Signals query offrant de nouvelles possibilités aux @ViewChild et consorts.

Amélioration en cours de l'écosystème des Signals​

Pour combiner au mieux les RxJS et les Signals, le package rxjs-interop (encore expérimental à l'heure actuelle) permet d'utiliser le meilleur des 2 mondes en permettant de transformer un Observable en Signals et inversement.

Un autre aspect de la réactivité des Signals passe par les opérateurs permettant de réagir aux changements de valeurs. Ainsi, en plus du computed qui est stable depuis plusieurs versions et l'Effect qui est toujours en developer preview, Angular s'attaque maintenant à faciliter le travail pour la gestion de l'asynchronisme via l'opérateur resource (et ses dérivés rxResource et httpResource), dont le cas d'usage principal est de permettre de récupérer des données via une API et de les utiliser comme Signals. D'ailleurs deux demandes de commentaires (RFC) ont récemment été publiées pour discuter de ce sujet.

Une bonne illustration faite par un membre de l'équipe d'Angular des différents outils liés aux Signals :

Un chantier qui débute est celui d'utiliser les signals au sein des formulaires, avec comme objectif, encore une fois, de faciliter l'expérience de développeur.

Les signals en dehors d'Angular​

La venue de signals permet aussi l'amélioration des librairies connues qui gravitent autour d'Angular.

Le premier exemple qui me vient à l'esprit est la librairie Ngrx qui propose des outils pour gérer l'état de l'application ou de composant. Ils ont ainsi intégré des sélecteurs de type signal dans leur store et component store, mais ils proposent aussi une librairie dédiée pour avoir un store directement en signal. Si le sujet vous intéresse, voici une série d'articles sur le sujet par Angular Architects.

Nouveau control flow (stable en v18)​

La version 18 a permis de murir les nouvelles fonctionnalités liées aux signals, mais a aussi introduit de nouvelles syntaxes dans les templates de composants, autrement appelées Control Flow, permettant de sortir les conditions des balises html et d'améliorer la lisibilité des templates.

Via l'ajout de cette syntaxe, l'équipe d'Angular a aussi ajouté le bloc @defer qui permet de charger paresseusement les composants/directives/pipe qui sont inclus dans le bloc.

En version 19 une nouvelle balise a fait son apparition, le @let permettant de définir une variable directement dans le template.

@let user = user$ | async;
@if (user) {
  <h1>Hello, {{user.name}}</h1>
}

L'hydratation incrémentale​

Un point moins mis en avant est le rendu côté serveur (Server side rendering, SSR), qui permet de générer une partie de la vue sur le serveur, permettant une amélioration des performances pour l'utilisateur, ou encore un meilleur référencement SEO.

Pour améliorer les performances au niveau de la réactivité du SSR, l'hydratation permet de réutiliser une partie du code généré côté serveur.

L'hydratation incrémentale vient optimiser l'hydratation en ciblant les parties à hydrater, cela fonctionne via le bloc @defer et permet d'hydrater le contenu du bloc uniquement lorsque l'évènement déclencheur du @defer est activé.

Angular sans zone.js​

Avec une disponibilité en mode expérimentale depuis la version 18, il est maintenant possible d'utiliser Angular sans zone.js avec à la clé une amélioration des performances de rafraichissement des vues. Pour refléter ce changement, l'équipe envisage d'ailleurs d'utiliser le terme "synchronisation" en remplacement de la "détection de changement".

Se passer de zone.js permettra :

• d'améliorer les performances en supprimant une libraire supplémentaire au bundle et toute la surcharge que ça implique, tout en optimisant la détection de changement et évitant certains bugs liés à zone.js.
• Un meilleur débogage avec un suivi simplifié de l'état de l'application et de ses mises à jour.
• De s'aligner sur l'architecture moderne d'Angular avec les Signals pour une réactivité propre et efficiente.

Nouveau format des composants (authoring format)​

Un autre point, est la recherche sur le nouveau format des composants (authoring format), avec pour objectif par exemple d'éviter la duplication d'import entre l'import JavaScript et l'import standalone :

import { Checkbox } from 'component-library';

@Component({
  selector: 'my-app',
  imports: [Checkbox], // <-- an extra import
  template: `<my-checkbox/>`
})
export class App {...}

Les réflexions n'en sont qu'à leurs débuts, plus d'infos sur ce sujet dans cette vidéo partagée par Matthieu Riegler.

Un peu dans la même veine, une communication récente fait mention de recommandation visant les noms des fichiers, le guide de style omettra le fait de suffixer les noms avec "component", "directive" ou "service". Et à la place, pour permettre aux différents outils de mieux supporter Angular, de mettre le préfixe "ng" (ng.html, ng.ts…).

Feedbacks de la communauté​

Parmi les derniers changements, les Signals et Control flow sont les 2 améliorations qui ont le plus d'impact positif pour les développeurs d'après l'enquête menée par l'équipe Angular.

Tips pour suivre les nouveautés​

Mise à jour de la documentation​

Sortie en même temps que la version 17, une nouvelle version de la documentation a été mise à disposition sur angular.dev.

Dans les apports notables, je trouve que l'intégration d'un bac à sable intégré est très pratique pour suivre le tutoriel, ou simplement pour faire des tests rapides dans le playground (et c'est toujours possible sur Stackblitz).

Contenu des versions​

Vous pouvez bien sûr retrouver ces sujets listés sur la roadmap officielle d'Angular. Permettant d'avoir un aperçu de l'ensemble des chantiers passés et en cours.

Mais avec le rythme de sortie de 2 versions majeures par an, avec dans chacune des versions des fonctionnalités en expérimentation ou en avant-première, il est parfois facile d'oublier ce que l'on peut utiliser sereinement pour son application en production. Il est bien sûr possible d'aller directement sur la documentation officielle pour voir si la fonctionnalité est stable, mais le Français Gerome Grignon porte un projet permettant de visualiser rapidement le statut des principales fonctionnalités sur Angular.courses/caniuse.

Mise à jour de vos applications​

Depuis quelque temps, pour simplifier la vie des développeurs lors des mises à jour, des "schematics" sont disponibles via l'outil de ligne de commande.

Il est ainsi possible de facilement passer ses composants en standalone, utiliser la nouvelle syntaxe de control flow ou encore passe les @Input des composants en signal en une commande.

Vous pouvez retrouver tous les schematics disponibles dans la documentation officielle de migration.

Et pour certains l'action est directement proposée dans VSCode, par exemple la conversion des @Input.

Conclusion​

Grâce aux efforts combinés de l'équipe et de la communauté, Angular a connu un regain de popularité face à React et VueJS. En adoptant certaines des meilleures fonctionnalités de ses concurrents, Angular maintient sa compétitivité en termes de performances et d'expérience de développement.

Je trouve d'ailleurs intéressant le feedback d'Alex Rickabaugh à ce sujet, et j'ai l'impression que les efforts fournis portent leurs fruits 🙂

Pour être honnête, l'un des plus grands moteurs de la « Renaissance Angular » a été un changement de culture de l'équipe au fil des ans, passant d'une vision des problèmes comme des problèmes de compétences à une vision des problèmes comme des problèmes de conception [du framework].

Liens​

Voici quelques ressources utiles (en anglais).

• Blogs
  • Angular Space
  • Angular Architects
  • Angular Love
  • Angular Experts
• Angular2 sur Reddit
• X
  • Minko Gechev (Angular product lead) - Bluesky
  • Matthieu Riegler (Angular team) - Bluesky
  • Alex Rickabaugh (Angular team) - Bluesky
  • Tomas Trajan (GDE) - Bluesky
  • Deborah Kurata (GDE) - Youtube - Bluesky
  • Armen Vardanyan (GDE) - Bluesky
  • Enea Jahollari(GDE) - Bluesky
  • Nivek (GDE)
  • Younes Jaaidi [français](GDE) - Bluesky
  • Evgeniy OZ
  • Rainer Hahnekamp - Bluesky
  • Daniel Glejzner - Bluesky
  • Gerome Grignon [français] - Bluesky
  • AngularDevsFr - Bluesky
• Autre
  • Ngxtension : Librairie d'utilitaires pour Angular
  • Visualisation de diagrammes RxJS
    • rxvisualizer.com : Beta de visualisation dynamique
    • thinkrx.io : Visualisation statique avec des comparaisons d'opérateurs

La tyrannie de la commodité : ce que nous coûte la facilité​

La Tyrannie de la commodité, qu'est-ce que c'est ?​

Traduction littérale de l'Anglais "tyranny of convenience", le concept n'est pas si récent. Evan Williams, co-fondateur de Twitter, le déclarait déjà en 2018 : « la commodité décide de tout ». Clef de voûte du marketing, certaines marques en ont même fait leur argument principal : "Pratique et intuitif", "Tous vos outils au même endroit". Pourtant, on devrait le savoir, un argument marketing est rarement un argument rationnel.

Nous savons que le fast-food est mauvais pour la santé, qu'il y a plein d'alternatives souvent plus savoureuses et meilleures pour la santé, pourtant, la facilité de passer au kebab semble souvent l’emporter. Et non seulement on a cédé à la facilité sur le coup, mais on crée un précédent qui va nous pousser à recommencer.

Lorsqu’une option est bien plus "simple" que les autres, les alternatives paraissent vite irrationnelles. La tyrannie de la commodité, ce sont tous ces choix que l'ont fait non pas parce que ce sont les meilleurs, les plus adaptés, les plus rationnels, mais parce que sortir de la commodité nous semble impossible, impensable. C'est le moment où la commodité n'est plus un atout, mais une contrainte.

L'IT est particulièrement sensible à cette problématique. Tenu par des objectifs d'efficacité et de rapidité, il est facile d'aller au plus simple et surtout, d'y rester. Et ce n'est pas nécessairement une mauvaise chose ! Comme le dit le dicton bien connu dans les métiers du numérique : inutile de réinventer la roue. Il faut savoir s'appuyer sur des solutions déjà existantes pour travailler plus efficacement. En revanche, il est important de s'interroger sur ce que cela nous coûte : cet écosystème clef en main deviendra-t-il une prison ? Quid de la dépendance à un seul outil, à une seule entreprise ? À quel moment devient-on esclave de la commodité ?

Commodité et Liberté : des conséquences à diverses échelles​

La commodité n'est pas en nécessairement mauvaise et n'est pas à fuir par principe. Cependant, elle peut créer une dépendance et une résistance au changement qui peut s'avérer délétère.

Un exemple dans lequel tout le monde se reconnaitra est le choix du système d'exploitation de notre matériel informatique, et particulièrement de nos terminaux mobiles. iOS ou Android ? Est-ce vraiment la rationalité qui détermine notre choix ? Si c'était le cas, nous n'aurions aucun mal à passer de l'un à l'autre quand une nouvelle fonctionnalité fait son apparition chez la concurrence. Pourtant, la plupart des utilisateurs·rices restent "fidèles" à leur système à chaque renouvellement de mobile, sans même s'interroger sur les alternatives. Cette "fidélité" va même parfois jusqu'à nous faire accepter des défauts majeurs (confidentialité, durée de vie de la batterie, obsolescence programmée...) pour ne pas changer nos habitudes.

Dans nos métiers, la tyrannie de la commodité peut avoir de nombreuses conséquences : elle peut nous empêcher de choisir le meilleur outil pour notre besoin, elle peut coûter cher parce que l'on reste prisonnier d'un environnement trop coûteux, car on en est dépendant. Elle nous empêche de voir et de réfléchir aux alternatives à ce qui nous semble le plus évident. Pour prendre un exemple parlant : une grande part (si ce n'est une majorité) de professionel·le·s du numérique préfère (ou gagnerait à) travailler sur macOS ou sur Linux. Pourtant, iels sont souvent contraint·es à utiliser Windows par... la tyrannie de la commodité. On a l'habitude de cet environnement, on a grandi avec. Pire ! On y est parfois contraint par les protocoles de sécurités de notre entreprise ou de nos client·es, car les VPNs, les antivirus, fournis par des sociétés tierces, ne supportent pas d'autres OS... ou pour un prix plus élevé. Pourtant, le système d'exploitation que l'on utilise va influencer grandement tous les choix d'outil que l'on va pouvoir utiliser !

La commodité et son influence sur l'innovation​

Au-delà de l’influence sur les choix individuels ou à l'échelle d'un projet, la commodité anime les grandes tendances technologiques et pose des freins à l'innovation. La tyrannie de la commodité joue un rôle important dans une logique du "too big to fail", ce moment où un outil est tellement dans une situation de monopole qu'il devient l'outil par défaut même s'il n'est ni le moins cher ni le plus adapté.

Encore une fois, prenons un exemple que nous connaissons tous : le site de vente en ligne Amazon.

Plus Amazon devient accessible, plus les gens l'utilisent. Et ce cycle renforce la portée et l'attrait d'Amazon, en faisant le choix privilégié et par défaut. Cependant, cette centralisation a un effet délétère : le monopole étouffe la concurrence. Ainsi, de nombreux produits, notamment informatique et numérique, ne sont plus disponibles ailleurs que sur Amazon. Vous cherchez un câble USB-C d'une certaine longueur, un chargeur de secours pour votre ordinateur, des coussinets de remplacement pour votre casque audio ? Vous avez très peu de chance de trouver la référence qu'il vous faut ailleurs que sur Amazon. Et même si vous la trouvez, cela coutera facilement deux fois plus cher ailleurs ! Par ailleurs, qu'importe si l'on n'est pas en accord avec les valeurs de cette entreprise, si la qualité est variable, si l'on cherche une alternative plus écologique ou locale : Amazon a tué la concurrence. Par commodité, il s'est imposé dans nos pratiques de consommation. Dans l'impossibilité de s'aligner, les autres distributeurs ont rendu les armes sur certaines références, laissant à Amazon le champ libre pour vendre des produits de moins bonne qualité ou dans des conditions éthiques discutables. La "commodité" n'est alors plus un choix rationnel : elle est devenue une contrainte. Elle empêche le développement d'une concurrence qui pourrait proposer des alternatives. Car l'absence de concurrence permet de moins se soucier de l'innovation et de la qualité ! Quand vous avez le monopole, moins besoin d'être compétitif.

Un autre exemple : chez zatsit, nous avons eu l'occasion dans le cadre de nos journées de recherche en greenIT de tester Scaphandre, un outil de monitoring de la consommation énergétique des clusters kubernetes. Open source, un tel outil permettrait d'avoir des mesures directes de consommation réelle. Problème : les fournisseurs cloud comme Google ou Amazon n'exposent pas ces métriques. Une excellente initiative qui est donc bloquée (pour l'instant) par le monopole des fournisseurs cloud. Bloquée dans son utilisation, mais aussi son développement : difficile de mobiliser la communauté FOSS autour d'un outil qui est inutilisable dans énormément des cas de production.

Lutter contre la tyrannie de la commodité : une hygiène du quotidien​

Une fois ce constat établi, on peut facilement se sentir découragé. Comment remettre en question des géants comme Windows, Google, Apple, Amazon ? Comment faire valoir dans nos équipes et dans notre entourage que "facile" n'est pas toujours un bon argument ? Nous vous proposons 3 axes, faciles à mettre en place dans votre quotidien et dans son environnement professionnel, pour lutter contre la tyrannie de la commodité :

1. Prendre toujours le temps de questionner :​

À chaque tournant de votre projet, à chaque choix technique, à chaque remplacement de matériel, prendre le temps de questionner les choix "évidents". Une bonne façon de savoir si nos choix sont dictés par la commodité est de se demander "si je prenais cette décision pour la première fois, est-ce que je ferais le même choix ?". Si la réponse est non, et particulièrement si la raison pour laquelle vous prenez cette décision est "par habitude" (pour ne pas avoir à transférer vos données/contacts, parce que vous avez l'habitude de l'UI, parce que c'est ce qui est fait partout ailleurs dans le projet, parce que votre cloud provider propose une solution clef en main, parce que c'est inclus dans notre offre, parce que c'est un outil que vous maitrisez déjà...) alors vous ne prenez pas une décision rationnelle : vous vous pliez au marketing et à la tyrannie de la commodité.

Prenez le temps d'envisager d'autres options, de regarder du côté de l'open source. Ne partez pas du principe que le plus évident est le plus rationnel.

2. Apprendre à repérer les situations à risques :​

Il est plus facile de lutter contre la tyrannie de la commodité avant d'en être victime. Certains concepts doivent nous mettre la puce à l'oreille au moment de choisir un outil : "Facile", "clef en main", "tout compris", "le plus utilisé". Ce genre de mot clef doit nous interroger. Soyons clair : il ne faut pas fuir la commodité par principe, mais être conscient de ses effets négatifs. "Facile" doit venir en bonus de "adapté". "Facile" n'est pas le synonyme d'"efficace". Et on sait que, de la mécanique automobile au développement d'application, il est souvent plus simple pour les entreprises fabriquant des outils de garder les utilisateurs·ices captifs·ves plutôt que de fournir les meilleurs outils et les plus adaptés. Au moment de choisir un nouvel outil, ou de faire un choix technique, soyons attentifs aux arguments de commodité : les décisions que nous prenons maintenant vont nous contraindre dans le futur. Faisons en sorte que ce soit pour de bonnes raisons.

3. Éduquer notre entourage :​

Comme nous l'avons vu, la tyrannie de la commodité a des effets plus larges qu'à l'échelle d'un projet, d'un choix technique, ou de l'achat d'un nouveau smartphone : elle appauvrit tout notre environnement technique, limite nos choix, et ralentit l'innovation. Pourtant, si vous essayez demain de convaincre vos collègues de ne pas utiliser Google, ou de passer de iOS à Android, vous risquez de vous heurter à un mur. Les habitudes sont difficiles à changer et la tyrannie de la commodité a cela de pernicieux qu'elle fait apparaître toutes les alternatives comme stupides, irrationnelles, irréalisables. Parler de la tyrannie de la commodité et de ses effets délétères (en partageant cet article par exemple 😊) peut permettre de faire changer les mentalités, en faisant prendre conscience à votre entourage et à vos collègues que ce qu'iels pensent être un choix dicté par leur rationalité est en réalité une contrainte, ou pire : une manipulation marketing. En cédant à cette facilité, iels limitent non seulement leurs options, mais celle de communauté entière.

La tyrannie de la commodité : une part d'un problème global.​

En réalité, la tyrannie de la commodité est une partie d'un problème bien connu dans le milieu du numérique : le "courtermisme". Pris dans des considérations de coût et d'efficacité, le milieu de l'entreprise a souvent tendance à aller vers une solution à court terme et à bas coût. En tant que professionnel·les du numérique, nous luttons déjà contre cette tendance, non pas par principe, mais par rationalité : Nous savons par exemple que prendre 20% de temps supplémentaire pour écrire des tests nous fera gagner du temps et de l'argent à moyen terme. Nous savons qu'il faut faire relire son code par ses pairs, qu'il faut être attentif aux bonnes pratiques, aux bons outils pour garder un code propre et maintenable à long terme. Mais nous savons aussi que tout est affaire de compromis et que l'on ne peut pas ignorer les contraintes de temps et de moyen.

Il ne faut pas tomber dans une position extrême où tout ce qui est efficace et pratique deviendrait suspect ! Connaître le concept de tyrannie de la commodité permet de rester vigilant et de reconnaitre plus facilement les situations qui pourraient, plus tard être problématiques. Elle nous rappelle aussi l'importance de maintenir une veille professionnelle active, de promouvoir l'open source pour toujours garder ses alternatives ouvertes, et que la commodité ne devienne pas une prison.

Dans cet article, nous allons vous guider, étape par étape, pour créer votre propre assistant IA local et le déployer dans votre environnement de développement (VSCode ici); à l’aide de LM Studio et de l’extension CodeGPT.

Disclaimer

Vous le savez sans doute, l'utiliation d modèles d'IA nécessitent beaucoup de ressources machine : un processeur performant, une carte graphique puissante (GPU) et une grande quantité de RAM sont généralement recommandés (LM Studio permet de choisir l’utilisation du CPU et/ou GPU, au passage).

Prérequis

Avant de commencer, assurez-vous d’avoir NodeJS d’installé en version 18+ et Visual Studio Code (VSCode).

Installation de LM Studio

👉 Allez sur le site de LM Studio et téléchargez la version adaptée à votre matériel.

👉 Une fois installée, il est temps de choisir le modèle le plus adapté à votre besoin.

Nous vous proposons de tester le nouveau modèle de Mistral AI, Codestral : un modèle qui supporte plus de 80 langages de programmation.

Il existe d'ailleurs des modèles alternatifs pour des assistants de code comme Code llama ou StarCoder si vous souhaitez comparer.

👉 Ouvrez LM Studio et sélectionnez la loupe (dans le menu de gauche) afin de rechercher le modèle Codestral via la barre de recherche :

👉 Une fois le modèle trouvé, cliquez sur le bouton Use in New Chat pour télécharger le modèle.

Patientez quelques instants, le temps de télécharger le modèle qui pèse un peu plus de 13 GB.

👉 Une fois téléchargé, accédez au menu Developer (icône Terminal sur la sidebar de gauche), puis sélectionnez le modèle à charger dans la barre du haut :

👉 Chargez le modèle Codestral que vous venez de télécharger.

Patienter quelques instants, le modèle se charge en mémoire.

Une fois le chargement terminé, il ne vous reste plus qu’à cliquer sur Start Server pour commencer à utiliser votre assistant.

La configuration de LM Studio est maintenant terminée.

Voyons comment effectuer son intégration dans VS Code.

Intégration dans Visual Studio Code

👉 La première chose à faire est de télécharger l’extension CodeGPT qui permet, en s’inscrivant sur leur site, d’accéder aux APIs de différentes IAs comme ChatGPT ou encore ClaudeAI.

Toutefois, ce n’est pas ce que l’on souhaite faire ici.

Nous cherchons à utiliser l'infrastructure de nos machines, plutôt que celles de serveurs distants, souvent alimentés avec une énergie à la provenance inconnue et dans un datacenter sûrement pas tout proche.

Une belle façon d’être un peu plus green et de réduire notre empreinte 🌱.

👉 Une fois l’extension installée, cliquez sur l’icône ChatGPT dans la sidebar de gauche, puis sélectionnez l’assistant à utiliser.

👉À la place de CodeGPT Plus (qui vous incite à utiliser les API des GAFAM de l’IA), choisissez LM Studio comme Provider Local.

Et voilà ! Le tour est joué.

Vous avez à présent un assistant d’aide à la programmation, qui utilise directement vos ressources locales pour fonctionner.

Qui vous a dit qu'il n'était pas possible de faire de l'IA frugale ?

Utiliser votre nouvel assistant

Pour vérifier que l’assistant fonctionne bien, nous allons lui demander de créer un composant Product Card en ReactJS avec une image, un nom du produit, une courte description, un prix et un bouton d’ajout au panier, en interagissant directement avec la fenêtre de chat via le prompt suivant :

Create a product card component in react with product image, product name, short description, price and add to cart button

Attention, les prompts sont à rédiger en anglais. Votre assistant ne fait pas encore la traduction automatique.

Une fois le prompt envoyé, l’IA générative utilise le modèle Codestral de votre LM Studio pour répondre.

Si vous vérifiez la fenêtre de votre LM Studio, vous verrez bien le prompt et la réponse dans les logs.

Conclusion

Le code généré par l’assistant n’est peut-être pas encore au niveau de ce que peut produire Bolt.new de StackBlitz ou v0.dev de Vercel, mais c’est déjà une première approche d’utilisation de l’IA beaucoup plus responsable (et économique).

Cet assistant se révèle toutefois plus efficace que ses alternatives, pour générer des tests unitaires à partir de votre code ou pour optimiser ce dernier.

Maintenant, c'est à vous de faire le reste :

• explorer les possibilités que vous offrent cet assistant
• tester d’autres modèles d’IA (en local) plus adaptés à vos besoins.
• en parler autour de vous, pour favoriser l'adoption de cette technique.

Aidez nous à avoir un impact en partageant cet article sur vos réseaux sociaux :

Crossplane se définit comme annoncé sur leur baseline :

Build control planes without needing to write code. Crossplane has a highly extensible backend that enables you to orchestrate applications and infrastructure no matter where they run, and a highly configurable frontend that lets you define the declarative API it offers.

...comme un orchestrateur de ressources multi-cloud.

Introduction​

Crossplane permet de définir des ressources de manière déclarative, et de les provisionner sur des clouds publics (AWS, Azure, GCP, etc.) ou privés (VMware, OpenStack, etc.).

Membre de la CNCF depuis 2020, ils ont rejoint le programme d'incubation (incubating) en 2021, dans la catégorie "Scheduling & Orchestration" ce qui en fait un projet prometteur, puisque synonyme de stabilité et d'utilisation en production.

Crossplane se rapproche du mode de fonctionnement de Terraform et apporte des fonctionnalités supplémentaires qui le font se démarquer :

• Définition de ressources de manière déclarative
• Réconciliation sur base du pattern des Kubernetes Operators

Crossplane est un projet open source, disponible sur GitHub sous licence Apache 2.0 et majoritairement développé par la société Upbound.

Intérêt​

Crossplane se démarque de ses concurrents par sa capacité à gérer des ressources et appliquer les modifications en live. Le pattern de réconciliation lui permet d'être réactif et d'appliquer les changements sur les ressources distantes en temps réel, qui est une vue de l'esprit étant donné que la réconciliation est une boucle qui s'exécute à intervalles réguliers.

Architecture​

Crossplane s'architecture autour de plusieurs concepts :

• Manipuler les ressources Cloud
• Orchestrer et ordonner la création des ressources
• Provisionner une architecture complexe
• Proposer un objet simple à manipuler

Concepts​

Provider​

Le Provider est le composant en charge de la gestion des ressources Cloud. Il est responsable de la communication avec l'API du Cloud Provider, de la gestion du cycle de vie des ressources.

Les providers sont labelisés Official (développés par Upbound) ou Community (développés par la communauté).

Chaque Provider s'installe avec des CRDs spécifiques qui définissent les ressources gérées par le Provider. Ces CRDs permettent de décrire l'objet distant à créer, mettre à jour ou supprimer.

Lien vers la documentation des CRDs dans Kubernetes

Exemple avec le Provider Google Cloud Pub/Sub.

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-gcp-pubsub
spec:
  package: xpkg.upbound.io/upbound/provider-gcp-pubsub:v1.8.3

Le Provider accède au Cloud Provider dès lors qu'il est configuré avec les informations d'authentification (clé API, token, etc.) au travers de l'objet ProviderConfig.

apiVersion: gcp.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: upbound-system
      name: provider-creds # Nom du secret qui contient les credentials
      key: creds # Nom de l'attribut du secret qui contient les credentials
  projectID: zatsit-crossplane-demo

Catalogue des Providers​

L'ensemble des Providers publiques sont disponibles sur la Upbound Marketplace.

Pour les Providers complexes, on retrouve le découpage par ressource sous la forme de Provider Family.

On retrouve donc des Providers pour les ressources EC2, S3, RDS, etc pour AWS, et de manière similaire pour les autres Cloud Providers. Tous ces Providers sont regroupés dans une Provider Familiy qui contrôle la configuration des Providers du Cloud Provider.

Prenons exemple du provider Google Cloud, on retrouve la hiérarchie suivante :

• Provider Family provider-family-gcp
• Provider Config ProviderConfig lié à au Provider Family
• Providers: provider-gcp-compute, provider-gcp-container, provider-gcp-appengine, etc

Dans l'histoire de Crossplane, les Providers historiques de AWS, Google Cloud et Azure étaient composés d'un seul agent responsable de la gestion de toutes les ressources du Cloud Provider. Face à l'installation d'un nombre massif de CRDs dans le cluster Kubernetes, les développeurs ont décidé de découper les Providers en plusieurs sous-Providers, un par ressource, ce qui réduit drastiquement le nombre de CRDs installés et améliore le ratio CRD-utilisés / CRDs-installés.

Managed Resource (MR)​

Le Managed Resource est l'objet qui représente la ressource distante à gérer. Il est défini par le Provider et est utilisé pour décrire la ressource à créer, mettre à jour ou supprimer.

Ce sont des objets Kubernetes qui sont créés dans le cluster Kubernetes et qui sont gérés par le Provider.

Exemple avec la ressource Topic du Provider Google Cloud Pub/Sub.

apiVersion: pubsub.gcp.upbound.io/v1beta1
kind: Topic
metadata:
  annotations:
    meta.upbound.io/example-id: pubsub/v1beta1/topic
  labels:
    testing.upbound.io/example-name: topic
  name: topic
spec:
  forProvider: {}

Ce simple manifeste suffit amplement pour créer un Topic dans Google Cloud Pub/Sub du même nom que le nom du manifest (défini dans metadata.name).

On distingue deux types de Managed Resources :

• Les Managed Resources de type Crossplane : gérés par les providers du Cloud Provider.
• Les Managed Resources de type Kubernetes : gérés par un autre contrôleur Kubernetes, externe à Crossplane.

Les deux types de Managed Resources possèdent leur avantages et inconvénients. On détaillera cela dans un prochain article.

Composition​

La Composition est un objet qui permet de définir un ensemble d'objets qui cohabitent ensemble dans le but de créer une architecture complexe.

La Composition est un objet Kubernetes qui est géré par Crossplane et qui est responsable de la création, mise à jour et suppression des objets qui le composent. Il est la pierre angulaire car c'est l'élément qui donne toute sa puissance en orchestrant les ressources.

Exemple avec une Composition qui crée les éléments suivants :

• Un Topic dans Google Cloud Pub/Sub
• Un Job dans Cloud Scheduler

---
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: job-notif
spec:
  compositeTypeRef:
    apiVersion: blog.zatsit.fr/v1alpha1
    kind: XJobNotif
  mode: Resources
  resources:
    - name: Topic
      base:
        apiVersion: pubsub.gcp.upbound.io/v1beta1
        kind: Topic
        metadata:
          annotations:
            meta.upbound.io/example-id: pubsub/v1beta1/topic
          labels:
            testing.upbound.io/example-name: topic
          name: dynamically-set
        spec:
          forProvider: {}
      patches:
        - type: FromCompositeFieldPath
          fromFieldPath: spec.name
          toFieldPath: metadata.name
            
    - name: Job
      base:
        apiVersion: cloudscheduler.gcp.upbound.io/v1beta1
        kind: Job
        metadata:
          annotations:
            meta.upbound.io/example-id: cloudscheduler/v1beta1/job
          labels:
            testing.upbound.io/example-name: job
          name: job
        spec:
          forProvider:
            description: Test job
            httpTarget:
              - body: dGVzdAo=
                httpMethod: POST
                uri: https://postman-echo.com/post
            region: us-central1
            schedule: "1 * * * *"
      patches:
        - type: FromCompositeFieldPath
          fromFieldPath: spec.name
          toFieldPath: metadata.name

Composite Resource Definition (XRD)​

La Composite Resource Definition (XRD) est un objet plus haut niveau qui a pour but de définir l'architecture interne de notre Composition en définissant 2 objets :

• La Composite Resource (XR) : l'objet instancié qui définira le cycle de vie de notre objet complexe
• Le Composite Resource Claim (XRC) : l'objet qui sera manipulé par l'utilisateur final et qui se veut simple

La XRD est un objet complexe en apparence qui est juste très structuré. Il comporte de façon très pragmatique 2 grandes sections :

• claim et spec : qui définissent la dénomination et la structure du Claim sous forme d'une CRD
• status : qui définit la structure du XR lors de son instanciation

La XRD définit à la fois la XRC et la XR afin de garantir une cohérence entre les deux objets manipulés. La XR n'a de sens que si les valeurs manipulées sont bien définies par les paramètres utilisateur.

En résumé, notre XRD est une CRD qui définit 2 autres CRDs : la XRC et la XR.

Voici un exemple de XRD pour notre Composition JobNotif :

---
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xjobnotifs.blog.zatsit.fr
spec:
  group: blog.zatsit.fr
  names:
    plural: xjobnotifs
    kind: XJobNotif
  claimNames:
    kind: JobNotif
    plural: jobnotifs
  versions:
    - name: v1alpha1
      referenceable: true
      served: true
      schema:
        openAPIV3Schema:
          properties:
            spec:
              type: object
              properties:
                name:
                  type: string
                  description: Name of the JobNotif
            status:
              properties: {}
              type: object
          type: object

Composite Resource Claim (XRC)​

La Composite Resource Claim (XRC) est l'objet qui est manipulé par l'utilisateur. Il a pour objectif d'être simmple et d'abstraire toute complexité liée à l'architecture en dessous.

Par exemple, pour notre Composition JobNotif, l'utilisateur final n'a pas besoin de connaître les sous-ressources créées en dessous, telle que le Service Account (SA) et ses credentials, la gestion des policies liées au SA ainsi que le stockage des valeurs sensibles dans le Secret Manager. Toute cette complexité doit être masquée pour ne fournir à l'utilisateur la seule véritable information utile : le nom du Topic.

Voici un exemple de XRC pour notre Composition JobNotif :

apiVersion: blog.zatsit.fr/v1alpha1
kind: JobNotif
metadata:
  name: jobnotif-sample
spec:
  name: my-jobnotif

Composite Resource (XR)​

La Composite Resource (XR) est l'objet qui est créé par Crossplane lors de l'instanciation de la XRC.

Il est responsable de la gestion des ressources sous-jacentes et de leur cycle de vie. On trouve les sous-objets managés dans la structure spec.resourceRefs.

# Extrait du yaml de l'objet XR
# kubectl get xjobnotifs/jobnotif-sample-hs772 -o yaml
apiVersion: blog.zatsit.fr/v1alpha1
kind: XJobNotif
metadata:
  name: jobnotif-sample-hs772
spec:
  resourceRefs:
  - apiVersion: pubsub.gcp.upbound.io/v1beta1
    kind: Topic
    name: jobnotif-sample-hs772-5ph7f
  - apiVersion: cloudscheduler.gcp.upbound.io/v1beta1
    kind: Job
    name: jobnotif-sample-hs772-p8vqk

La XR expose également l'état de l'objet dans sa globalité dans la structure status.

# Extrait du yaml de l'objet XR
# kubectl get xjobnotifs/jobnotif-sample-hs772 -o yaml
apiVersion: blog.zatsit.fr/v1alpha1
kind: XJobNotif
metadata:
  name: jobnotif-sample-hs772
status:
  conditions:
  - lastTransitionTime: "2024-11-28T12:00:40Z"
    reason: ReconcileSuccess
    status: "True"
    type: Synced
  - lastTransitionTime: "2024-11-28T12:01:05Z"
    reason: Available
    status: "True"
    type: Ready

On y trouve enfin les données manipulés et stockées pour les réutiliser dans les autres objets manipulés dans la composition.

# Extrait du yaml de l'objet XR
# kubectl get xjobnotifs/jobnotif-sample-hs772 -o yaml
apiVersion: blog.zatsit.fr/v1alpha1
kind: XJobNotif
metadata:
  name: jobnotif-sample-hs772
status:
  resources:
    job:
      name: jobnotif-sample-hs772-p8vqk
    topic:
      name: jobnotif-sample-hs772-5ph7f

Approche Plateforme​

Crossplane se veut dichotomique en proposant une approche plateforme en distinguant 2 personas :

• Le développeur de la plateforme : qui consomme les ressources mises à disposition
• L'ingénieur plateforme : qui compose les ressources et les expose aux développeurs

Toute la complexité réside dans la définition du contrat de service entre les deux personas ainsi que la gestion des ressources sous-jacentes.

Une fois le contrat clair, le développeur écrit le manifest (XRC) qui décrit le besoin fondamental.

Cette approche amène des avantages intéressants qui en font un outil pertinent pour les équipes plateforme :

• La simplicité et la lisibilité des objets manipulés
• La réutilisation des objets
• L'autonomie des développeurs

Conclusion​

Crossplane est un outil qui permet d'abstraire la complexité des ressources Cloud et de les manipuler de manière déclarative.

Cette rapide introduction à Crossplane vous permet de comprendre les concepts de base et les forces de la solution. Dans un prochain article, nous entrerons plus en détail sur l'utilisation de Crossplane avec des objets plus complexes et des cas d'utilisation plus avancés.

Il est important de noter que Crossplane est un outil qui s'adresse à des équipes plateforme qui ont une bonne connaissance de Kubernetes et des ressources Cloud. Cet outil n'est pas à mettre sur tous vos projets, car il apporte une complexité supplémentaire qui n'est pas toujours nécessaire et qui peut engendrer des coûts (sous toutes formes possibles) supplémentaires.

Vous trouverez dans un prochain article un exemple concret d'utilisation de Crossplane pour provisionner une architecture qui manipule des objets non-predictifs.

Liens utiles​

• Site officiel de Crossplane : crossplane.io
• GitHub Crossplane : github.com/crossplane/crossplane
• CNCF Crossplane : cncf.io/projects/crossplane

Il était donc évident pour nous de participer activement à cet événement, en contribuant sur des projets qui nous tiennent à cœur, ou que nous utilisons au quotidien.

Faut-il rappeler ce qu'est l'open source ?​

L'open source est un modèle de développement qui repose sur la collaboration et le partage. Les projets open source sont accessibles à tous, permettant à chacun de consulter, modifier et/ou partager le code.

Le mouvement open source est animé par une communauté mondiale de développeurs (mais pas que...) qui donnent de leur temps pour faire évoluer les projets. Le code est hébergé sur une multitude de plateformes, dont les plus connues sont GitHub et GitLab.

Qu'est-ce que le Hacktoberfest ?​

Le Hacktoberfest est un événement annuel qui se déroule tout au long du mois d'octobre. Il a pour objectif d'encourager les contributions à des projets open source en récompensant les participants qui réalisent des pull requests/merge requests sur des dépôts publics.

L'année 2024 sonne la 11ème édition du Hacktoberfest, événement sponsorisé par DigitalOcean, Cloudflare et Quira, et pour lequel l'engouement ne cesse de croître. C'est l'occasion pour des milliers de développeurs, étudiants, passionnés et/ou curieux de rejoindre la communauté open source, d'apprendre, de partager, voire de s'amuser.

Nos contributions au Hacktoberfest 2024​

Nous avons mis le collectif à contribution sur tout le mois d'octobre, pendant nos midis à l'agence pour certains, et lors de notre zatsday d'Octobre, pour contribuer à des projets open source.

Consul Democracy - Amélioration de l'interface utilisateur​

• Projet : Consul Democracy
• Description : Consul Democracy est une plateforme de participation citoyenne. (Consul Democracy - Open Government and E-Participation Web Software)
• Contributeur : Nicolas FOURRE
• Pull Request : Fill in space in social buttons when options are turned off

Impact Framework - Amélioration de la documentation​

• Projet : Impact Framework - Documentation
• Description : Documentation pour le projet Impact Framework de la Green Software Foundation. (Documentation website for the Impact Framework project)
• Contributeur : Quentin BURG
• Pull Request : Fix example in quick-start.md

AsyncAPI - Amélioration de l'experience utilisateur​

• Projet : AsyncAPI - Website
• Description : Site web de AsyncAPI (AsyncAPI specification website)
• Contributeur : Guillaume GAYOT
• Pull Request : fix(migrating-to-v3): fix mark down to ensure correct highlighting

Cocogitto - Gestion des identifiants utilisateur dans la Github Action​

• Projet : Cocogitto - Github Action
• Description : Github Action pour vérifier la compliance au conventional commit. (A github action to ensure your current gitlog respect the conventional commit specification)
• Contributeur : Guillaume GAYOT
• Pull Request : Feat/add input for profile

Crossplane Assistant - Création de la documentation du projet​

• Projet : Crossplane Assistant - Documentation
• Description : Documentation du projet Crossplane Assistant (Crossplane Assistant documentation website)
• Contributeur : Germain LEFEBVRE
• Pull Request : feat: Full website documentation

Mocked API - Ajout d'une nouvelle fonctionnalité​

• Projet : Mocked API - Github
• Description : Ajout d'une fonctionnalité sur l'envoi de mail
• Contributeur : Guillaume GAYOT
• Pull Request : feat(emails): add endpoint for random email using user names #368

Pourquoi promouvoir l’open source ?​

Chez zatsit, nous croyons fermement que l’open source est un véritable tremplin pour l’innovation et la démocratisation des technologies, de la simple librairie de développement jusqu'à la gestion complète d'un CRM.

En participant au Hacktoberfest, nous promouvons cette culture de partage et de collaboration. Pour nous, chaque contribution est importante, qu’elle soit technique ou non, et permet de faire avancer les projets.

Voici quelques raisons pour lesquelles nous encourageons l’open source :

• Accessibilité : Le code source est public et permet à toute personne/développeur, quelle que soit sa localisation, d'y accéder, d’apprendre, d’utiliser, de partager et d'y contribuer.
• Innovation : La communauté open source regorgent de talents, et c'est tous ensemble que les projets les plus innovants peuvent voir le jour. L'exposition des projet au grand public permet de diffuser le savoir des plus innovants et partager cette connaissance.
• Transparence et sécurité : Le code source est publique donc la transparence est totale, ce qui permet à la communauté d’auditer, d’identifier et de corriger les failles de sécurité plus efficacement.
• Indépendance technologique : L’open source permet aux entreprises et aux utilisateurs de ne pas dépendre d'un provider en particulier et ainsi adapter les outils selon leurs besoins.
• Gratuité : La plupart des projets open source sont gratuits, ce qui permet à tous d’y accéder, de les utiliser voir de les modifier (fork).

Remerciements à la communauté open source​

Le Hacktoberfest est un moment privilégié pour remercier toutes les personnes qui font vivre cette communauté. Que vous soyez développeur, traducteur, testeur ou simple utilisateur, votre contribution est précieuse. C'est grâce à vous que des projets d’envergure internationale voient le jour, évoluent, et restent accessibles à tous.

Nous remercions tous les contributeurs de zatsit. Ce mois d'octobre a permis de mettre en lumière nos efforts sur la partie open source. Mais cet engagement ne s'arrête pas au mois d'octobre, il est permanent et nous continuons de contribuer au sein de la communauté tout au long de l'année.

Rejoignez-nous pour le prochain Hacktoberfest​

Le Hacktoberfest est une aventure collective ouverte à tous, des débutants aux experts. Si vous souhaitez vous lancer ou approfondir vos compétences, rejoignez-nous ! Chaque contribution, même minime, aide à faire avancer la technologie.

Ensemble, continuons à construire de meilleurs outils, plus justes et plus accessibles.

Vous avez aimé ce post ? Partagez le !

Ca tombe bien, on a la solution pour vous : Realworld !

Realworld, c'est quoi ? 🤔​

Realworld est un projet open-source se basant sur un clone du site blog Medium.com. Il a pour objectif de montrer comment implémenter une application web moderne en utilisant différents frameworks et langages de programmation.

Comment ? me direz-vous. Très simple, il suffit de suivre les spécifications de l'API pour implémenter les fonctionnalités de base d'un site de blog.

L'avantage de cette approche est que le site permet de mixer le frontend et le backend de votre choix parmi plus de 100 implémentations de l'API le tout se reposant sur cette même API définie.

C'est un excellent moyen de partager vos connaissances, pourquoi ne pas contribuer en ajoutant votre propre implémentation ?

N'hésitez pas à partager ce projet à vos connaissances, c'est une excellente ressource pour apprendre de nouvelles technologies !

Lundi ! Arrivée dans les locaux, je suis accueilli par Flavien (un des co-fondateurs) et Océane (notre chargée de missions RH de choc). Un bureau m'attend avec quelques goodies estampillés aux couleurs de l'entreprise : gourde en métal recyclé, sweat (dont le fabricant et membre de fairwear.org), sticker et un petit mot d'accueil qui me font très plaisir.

La matinée commence par la partie administrative (ce que tout le monde « adore », n'est ce pas ?)

• les divers documents à fournir et quelques validations d’identité habituelles.
• On active mes accès à Ekip. Je découvre ainsi les tickets restaurants écoresponsables.
• Puis avec Océane on passe en revue les accès aux outils qui permettent le suivi pour mes futures missions. D'ailleurs, zatsit a mis en place une plateforme dédiée pour l'onboarding des consultants, permettant de mettre en avant les quelques « formations » a dérouler pour être opérationnel.

On reparle avec tous le monde de ce l’on veut construire à l’avenir et des impacts que veut avoir zatsit sur les aspects sociétal et environnemental.

Ce qui m’amène à vous parler du choix sur le matériel qu’a fait la société.

Mon meilleur moment de la journée : la découverte de mon outil de travail​

Peu de temps avant mon arrivée, j’ai reçu un message qui me demandait de choisir la configuration de mon futur poste de travail Framework.

J’ai ainsi découvert leur concept : proposer du matériel réparable et évolutif. Ce choix permet à zatsit de rester cohérent dans sa politique environnementale et avoir un impact le plus restreint possible sur la planête.

J’ai donc choisi les différents éléments de ma machine : un 13 pouces avec coque en aluminium, le processeur, la ram, le disque, les extensions… Et pour le fun, le montage à faire par mes soins pour prendre en main l'assemblage du hardware.

Donc tout était là, dans un carton contenant les diverses parties de mon ordinateur. Quand on a l’habitude de monter des configurations, et comme tout est suffisamment indiqué sur la carte mère, l'assemblage se fait plutôt facilement et en quelques minutes : on installe le disque SSD et la mémoire, on referme avec le couvercle, qui est le clavier, on serre quelque vis avec l’outil qui est fournit, et zatsit !

Le petit plus sympa : le contour de l’écran est amovible et il existe plusieurs couleurs. Moi, j’ai choisi le orange.

Pour pouvoir alimenter la machine et la connecter à des périphériques, il y a 4 emplacements qui peuvent recevoir des modules d’extension en tous genres : USB type A ou C, HDMI, Ethernet et autres que l'on peut interchanger, et à chaud.

Et pour certaines extensions, on peut également y ajouter un peu de couleur.

Une fois tout en place, j’ai installé une distribution Linux (Ubuntu 24.04) à partir d’une clé USB que j’avais préparé en avance en suivant les indications fournies sur le site du fabriquant.

Et tout était fonctionnel au premier démarrage !

J’ai commencé à travailler sur ce poste après avoir configuré un environnent de développement. Je suis enthousiaste à l’idée d'utiliser ma machine lors de mes missions.

Parcourir le site de Framework Framework est intéressant :

• On y découvre que beaucoup de matériaux constituant les postes de travail sont en bonne partie recyclés.
• Qu’il est aussi possible de commander tous les composants séparément (cela va jusqu'au kit de visserie) ce qui permet de réparer ou de faire évoluer sa configuration facilement au fil des années (Idée que je trouve intéressante quand on à déjà ouvert un ordinateur portable et de constaté que l’on ne pourra pas faire grand chose pour se dépanner)
• Pour chaque composant proposé sur la marketplace, il existe un tutoriel de remplacement avec la difficulté, les étapes et le temps nécessaire à l'opération. Ce qui permet d'effectuer facilement la maintenance de son poste de travail par ses propres moyens.

En attendant de démarrer mon nouveau projet client...​

En attendant mon démarrage chez un client, j'en ai profité pour commencer les Classrooms élaborées par zatsit.

Les premiers ateliers m’ont permis de découvrir les principes de l’éco-conception ou d’étudier et de comprendre les solutions de monitoring pour l’empreinte carbone de projets cloud.

La société veut sensibiliser ses collaborateurs aux impacts environnementaux de nos métiers.

Des sujets très intéressants et que j’avais un peu survolé jusqu’à aujourd’hui. Cela va impacter ma façon de concevoir mes futurs projets en tant que technical leader.

J'ai pu collaborer à un premier projet, qui m'a fait découvrir certaines solutions de Firebase et Google Cloud Platform, auquel mes collègues pourront contribuer dans les semaines qui arrivent.

Mon avenir chez zatsit ?​

Je suis persuadé que les mois à venir vont être enrichissants et vont me faire grandir.

D’une part, l’équipe zatsit est à l’écoute quant à mes souhaits sur le périmètre de mes futures missions, mes envies de découvrir d’autres écosystèmes chez nos clients, et de me donner l’opportunité de faire mes preuves en tant que tech lead.

D’autre part, je vais pouvoir participer à des projets internes toujours en lien avec les convictions de la société qui vont favoriser les échanges au sein d’un collectif de passionnés.

Pour donner un exemple, on se prépare à participer à l’Hacktoberfest, événement qui encourage les développeurs à contribuer sur des projets open source. Il se peut d'ailleurs que l’on se croise lors d’un BBL, ou d’un Meetup sur des sujets passionnants organisé par zatsit

Alors, prêt à rejoindre l'aventure zatsit ?

Mais dans une démarche d’éco-conception et de performance, comment savoir si la librairie que l’on vient d’installer est la meilleure ? Ou la plus adaptée ? A-t-elle un impact sur le poids de mon application ?

Pour avoir plus d’information sur les librairies JavaScript que vous utilisez, un petit outil en ligne vous permet d’analyser leur impact sur le poids de votre application, mais également pour les applications front-end, l’impact sur le temps de chargement.

Cet outil, c'est BUNDLEPHOBIA ! (https://bundlephobia.com/)

Voici un petit exemple de ce que propose “bundlephobia” pour la librairie Axios, libraire bien connue des développeurs front-end et back-end (Node.js) qui permet d’effectuer des appels HTTP.

On retrouve plusieurs informations sur la librairie :

• sa dernière version, ici la 1.7.2
• savoir si la librairie utilise le “tree-shaking” ou non (ce qui permet une réduction du bundle généré si on n'utilise pas toutes les fonctions de la librairie)
• si la librairie est sensible aux interférences avec d’autres librairies tierces
• le nombre de dépendances qu’elle possède, ici 3 dépendances
• le poids de la librairie minifiée ou minifiée et compressée
• le temps de chargement de cette librairie en slow 3G et 4G (ce temps peut être réduit avec l’utilisation du “tree-shaking”)
• l’évolution du poids de la librairie au fil des versions
• la composition de la libraire (si le code est majoritairement interne à la librairie ou provient des dépendances), ici 99,8% du code est du code source de la librairie.

Petit bonus, “Bundlephobia” propose des alternatives à l’utilisation de la librairie, avec l’impact sur le poids du bundle. Ici, “Bundlephobia” propose “Phin” comme alternative qui est aussi un client HTTP pour Node.js. Ce dernier est 66% plus léger, mais attention, il ne propose peut-être pas toutes les fonctionnalités d’Axios, il vous revient le choix de tester ou non. Vous pouvez également proposer d’autres librairies alternatives à Axios et venir enrichir la base de donnée de “Bundlephobia” et contribuer à son développement.

À vous maintenant, de tester vos package.json pour tenter de réduire la taille de vos applications front-end ou Node.js pour plus de performance et pour améliorer leur empreinte carbone !

L'empreinte de l'industrialisation est avérée dans l'augmentation, des gaz à effet de serre, mais l'empreinte liée aux matières premières nécessaires à cette industrialisation et à ses produits finis l'est moins. Entre les deux, il y a bien sûr la consommation énergétique liée à l'extraction, la fabrication, la distribution et l'utilisation.

Je vous propose une série d'articles consacrée aux impacts du numérique sur notre environnement et nous commençons par une des sources : les matières premières, surtout les métaux.

Mine de rien, ça en fait des cailloux !​

Nous pourrions prendre d'autres produits de la vie courante pour illustrer les propos, mais nous nous intéressons ici au numérique. Ces dernières décennies, il y a eu énormément de progrès dans les domaines de l'informatique, de l'électronique, de l'optique et pas mal d'autres choses en "ique". Ces innovations ont nécessité toujours plus de matériaux, différents, plus rares les uns que les autres et disons-le, personne n'a encore eu l'idée de faire massivement mieux avec moins.

Il y a quelque temps j'ai eu la chance d'assister à deux évènements pleins de pédagogie :

• La conférence d'Aurore Stéphant aux APIdays (même si j'avais déjà vu certaines de ces interventions sur Youtube et notamment ses deux passages chez Thinkerview).
• Un Meetup Techrocks en début d'année sur le sujet qui nous occupe.

L'exploitation minière, toujours plus​

À travers les différentes époques, la demande en métaux n'a jamais cessé de croître : il y a pu avoir des ralentissements dûs à des évènements géopolitiques ou sanitaires (guerres, épidémies...), mais la demande est toujours croissante.

Source : https://www.systext.org/node/2058

Plus nous avançons dans le temps et plus nous trouvons des propriétés intéressantes à des métaux et autres éléments et des applications à échelle industrielle. À tel point que nos smartphones en sont truffés, je vous invite à visiter cette démo en ligne de Systext de composition en métaux d'un smartphone qui donne le résultat ci-dessous, avec pas moins de 60 éléments :

Source : Systext

Et oui, avec des composants comme l'Arsenic et l'Antimoine, certes en quantité minime et stabilisé dans votre smartphone, mais qu'en est-il de leur exploitation ?

Le problème c'est que les métaux sont inégalement présents dans les sols et quand on trouve plus facilement du fer et de l'aluminium, il faudra dans le meilleur des cas extraire 1 tonne de minerai pour obtenir 1g d'or.

Il existe donc des mines qui sont spécialisées dans l'extraction d'un ou plusieurs éléments, mais là où on va trouver un métal plus abondamment par exemple, on va aussi en trouver plein d'autres.

Cette infographie nous explique que pour chaque élément trouvé (au centre), on a de fortes chances de trouver les autres.

• Plus les autres éléments sont proches du centre, plus ils ont de chance d'être récupérés comme co-produit
• Plus ils sont proches de l'extérieur et plus ils ont de risques d'être rejetés dans les déchets miniers

Pour extraire des métaux de la roche, il y a des procédés mécaniques, thermiques, chimiques pour par exemple partir de la roche et obtenir des cathodes de cuivre. Tout cela avec une consommation d'eau et d'énergie phénoménale. Dans les exemples de cet article, nous sommes loin de l'image du mineur avec sa pioche sur l'épaule ou du prospecteur américain qui filtre du sable au bord de la rivière. On parle plutôt de machines gigantesques, d'explosifs et d'échelle difficilement imaginable.

Source : Systext

Il faut creuser un gros trou ?​

Vous avez peut-être déjà vu les photographies de Dillon Marsh qui montre "à l'échelle" la taille des mines en elle-même, leur emprise sur les espaces autour, en regard de ce qui en est extrait comme produit fini.

Ci-dessous, on peut se rendre compte, avec la représentation de la tour Eiffel, de la taille d'un site (extraction + exploitation + emprise en surface des déchets) pour la mine de cuivre de Palabora

Située en Afrique du Sud, cette mine a été exploitée pendant presque 40 ans. (plus de détail sur cette mine avec ce lien).

D'autres exemples de mines gigantesques existent (cette fois c'est du charbon, mais ça symbolise bien l'extraction minière), plus proches de nous, comme la Photo de la mine de Hambach en Allemagne.

Source : Wikipedia / Johannes Fasolt

Quelles sont les conséquences de l'exploitation minière ?​

La raison principale de cette exploitation est bien entendu d'approvisionner toutes nos industries : transports, énergie, armement, agriculture... enfin tout ce qui nécessite aujourd'hui des métaux, c'est à dire à peu près tout, dans sa composition, sa construction ou sa logistique.

Faites l'exercice : "Quel artefact utilisez-vous dans votre quotidien qui n’est pas dépendant de l’industrie minière dans sa fabrication, sa vente, son transport ?"

Conséquences écologiques​

Elles sont nombreuses : la pollution de l'air, des sols et de l'eau autour des sites est importante en "fonctionnement" normal, mais en cas d'accident c'est encore pire. On peut lire par exemple :

• Sur le site de l'ARIA une catastrophe au Brésil en 2015, un village de 620 habitants est englouti suite à une rupture de barrage de déchets de minerai de fer. 19 personnes trouveront la mort, plusieurs rivières seront polluées, une pollution se propageant jusqu'à l'océan.
• Toujours sur l'ARIA on trouve une catastrophe survenue en Espagne suite à la rupture d'une digue d'un bassin de stockage de déchets de pyrite. Des millions de tonnes d'eaux acides et de boues sont déversées dans la rivière Rio Agrio puis le Guadimar.
• un dernier exemple en Russie où on peut voir une rivière "sanglante" résultat de fuites de minerai. L'article expose que 210 000 personnes travaillent dans les environs pour cette industrie qui représente un cinquième du nickel mondial...

Des procès sont régulièrement intentés contre les exploitants, cependant ça ne permet pas de réparer les dommages occasionnés. Au-delà des accidents, la fin d'une exploitation d'un site minier ne signifie pas la fin de sa pollution, au contraire.

On ne dépollue pas un site minier, tout simplement parce que ce serait trop long, trop couteux, voire impossible. Chaque exploitation a donc un effet irréversible sur son environnement.

Conséquences politiques et sociales​

L'extraction minière est aussi source de conflits politiques et sociaux. Les ressources ne sont pas également réparties sur le globe et dans certains pays les conditions de travail des adultes et aussi des enfants sont assez "souples", dirons-nous, à l'égard de la filière.

Lors du meetup Techrocks du 8 février 2024, j'ai pu apprendre les démarches entreprises, par exemple, par Fairphone qui tente sur le long terme d'améliorer les conditions sociales autour des sites où elle source ses matériaux. Description de la stratégie disponible en ligne.

Fairphone s'est donc déjà confrontée à la réalité du travail des enfants qui sont employés sur certaines exploitations. Une stratégie de rémunération directe des "mineurs" permet d'éliminer des intermédiaires et d'améliorer les conditions sociales des familles. Un travail qui leur a, par exemple, pris 6 ans pour le cobalt.

Quelles solutions pour diminuer l'impact ?​

Ne soyons pas pessimistes sur la capacité de l'Homme à trouver des solutions, mais nous passerons forcément à une diminution de l'usage des métaux et à l'augmentation de leur recyclage. D'abord, parce que la teneur en métaux baisse dans les exploitations et ensuite parce que ça coutera toujours plus d'énergie, qui est, elle aussi, non illimitée.

Alors à l'échelle du numérique, que pouvons-nous faire ?

Se poser les bonnes questions sur les usages toujours plus gourmands en ressources : concevoir mieux pour utiliser plus longtemps ! Cela passe par une meilleure analyse des besoins, de faire des compromis sur les données dont on a réellement besoin, de la richesse des fonctionnalités qui induit souvent plus de complexité et donc un besoin de performance.

Tristant Nitot, lors du dernier DevFest Lille, nous expliquait clairement que l'amélioration de la puissance de calcul (illustrée par la loi de Moore) a sans cesse été partiellement annulée par la baisse de la performance et la complexité croissante des softwares.

Nous aurons chez zatsit l'occasion de vous reparler des thèmes, des outils et des méthodologies autour de l'éco-conception.

Bien choisir son matériel est aussi une réalité, à laquelle tente de répondre Backmarket par exemple. Acheter un article reconditionné permet de réduire l'impact de création d'un nouveau modèle, de son transport, de sa logistique... Il faut 6 à 7 ans d'utilisation d'un smartphone pour "absorber" son impact, alors en changer tous les 2 ans parait compliqué à justifier. Au-delà de l'obsolescence réelle, il y a l'obsolescence psychologique : le marketing qui nous martèle chaque jour qu'un stockage plus important, un énième objectif photo et des millions de pixels supplémentaires sont incontournables et nous changeront la vie.

Le site halteobsolescence.org vous permet de comprendre les mécanismes de l'obsolescence programmée et d'agir.

Pour terminer, vous avez peut être entendu parler de "l'éco design" directive signée en juin 2023, qui sera mise en oeuvre en mars 2025 et obligera les fabricants à fournir 5 ans de support après la fin de la mise sur le marché d'un produit. Donc, un téléphone ou ordinateur en vente une seule année en 2025 devra avoir un support jusqu’en 2030 !

En France aussi, la loi AGEC demande aux acteurs publics d'avoir un minimum de 20% d'achats de matériel reconditionné, ce qui pose quelques problèmes dans l'approvisionnement aujourd'hui, mais espérons que la situation s'améliore.

On associe souvent l'empreinte écologique du numérique à la consommation d'énergie, sur laquelle nous ferons un prochain focus, mais cet article souhaitait mettre l'accent sur l'envers du décor des équipements numérique et leurs conséquences.

Soyez curieux à votre tour, cherchez de l'information dans les sources citées (et d'autres) pour vous faire votre propre opinion et peut-être changer quelques habitudes.

Ressources :​

• USI 2022 "Ruée minière au XXIè siècle : jusqu'où les limites seront-elles repoussées ?"
• Compléments de sources d'entretien
• Rapport Tome 2 · Meilleures pratiques et mine « responsable »
• Ressources minières en France
• By-product metals are technologically essential but have problematic supply

Il y a une semaine, Google a dévoilé Gemini, son modèle d'IA le plus puissant et flexible à ce jour, disponible en trois tailles : Ultra, Pro et Nano.

Aujourd'hui, nous sommes ravis d'annoncer que Gemini Pro est désormais accessible publiquement sur Vertex AI, la plateforme d'IA de bout en bout de Google Cloud, comprenant des outils intuitifs, une infrastructure entièrement gérée et des fonctionnalités intégrées de confidentialité et de sécurité. Avec Gemini Pro, les développeurs peuvent désormais créer des "agents" capables de traiter et d'agir sur des informations.

Créez des agents d'IA de qualité professionnelle à grande échelle avec Gemini Pro sur Vertex AI​

Vertex AI permet de personnaliser et de déployer Gemini, donnant aux développeurs le pouvoir de créer de nouvelles applications différenciées capables de traiter des informations à travers le texte, le code, les images et la vidéo. Avec Vertex AI, les développeurs peuvent :

• Découvrir et utiliser Gemini Pro, ou choisir parmi une liste sélectionnée de plus de 130 modèles de Google, open source et de tiers, répondant aux normes strictes de sécurité et de qualité de l'entreprise. Les développeurs peuvent accéder aux modèles via des API faciles à utiliser pour les intégrer rapidement dans des applications.

• Personnaliser le comportement du modèle avec une expertise spécifique au domaine ou à l'entreprise, en utilisant des outils de réglage pour enrichir les connaissances de formation et ajuster même les poids du modèle lorsque cela est nécessaire. Vertex AI propose une variété de techniques de réglage, notamment la conception de prompt, le réglage basé sur l'adaptateur tel que Low Rank Adaptation (LoRA), et la distillation. Nous offrons également la possibilité d'améliorer un modèle en capturant les commentaires des utilisateurs grâce à notre prise en charge de l'apprentissage par renforcement à partir des commentaires humains (RLHF).

• Augmenter les modèles avec des outils pour aider à adapter Gemini Pro à des contextes ou des cas d'utilisation spécifiques. Les extensions et connecteurs Vertex AI permettent aux développeurs de lier Gemini Pro à des API externes pour des transactions et d'autres actions, de récupérer des données à partir de sources externes ou d'appeler des fonctions dans des bases de code. Vertex AI offre également aux organisations la possibilité d'ancrer les sorties du modèle de base dans leurs propres sources de données, contribuant ainsi à améliorer la précision et la pertinence des réponses du modèle.

• Gérer et mettre à l'échelle les modèles en production avec des outils spécialement conçus pour garantir que, une fois les applications construites, elles peuvent être facilement déployées et entretenues. À cette fin, nous introduisons une nouvelle façon d'évaluer les modèles appelée Automatic Side by Side (Auto SxS), un outil automatisé à la demande pour comparer les modèles. Auto SxS est plus rapide et plus rentable que l'évaluation manuelle des modèles, ainsi que personnalisable pour différentes spécifications de tâches afin de traiter de nouveaux cas d'utilisation de l'IA générative.

• Construire des agents de recherche et de conversation dans un environnement à faible code / sans code. Avec Vertex AI, les développeurs de tous niveaux de compétence en apprentissage automatique pourront utiliser Gemini Pro pour créer des agents d'IA engageants de qualité professionnelle en quelques heures et jours au lieu de semaines et mois. Prochainement, Gemini Pro sera une option pour alimenter les fonctionnalités de résumé de recherche et de génération de réponses dans Vertex AI, améliorant ainsi la qualité, la précision et les capacités d'ancrage des applications de recherche. Gemini Pro sera également disponible en version preview en tant que modèle de base pour les agents de conversation vocale et de chat, offrant des interactions dynamiques avec les utilisateurs et prenant en charge un raisonnement avancé.

• Proposer de l'innovation de manière responsable en utilisant les filtres de sécurité de Vertex AI, les API de modération de contenu et d'autres outils d'IA responsables pour aider les développeurs à s'assurer que leurs modèles ne produisent pas de contenu inapproprié.

• Aider à protéger les données avec les contrôles de gouvernance des données et de confidentialité intégrés de Google Cloud. Les clients restent maîtres de leurs données, et Google n'utilise jamais les données des clients pour former nos modèles. Vertex AI offre une variété de

Indemnisation sur les sorties de modèles générées​

L'approche complète de Google en matière d'IA est conçue pour aider à maintenir la sécurité et la protection de nos clients. Nous adoptons une approche d'indemnisation à deux volets, une première dans l'industrie, pour donner aux clients de Cloud la tranquillité d'esprit lors de l'utilisation de nos produits d'IA générative. Aujourd'hui, nous étendons notre indemnisation sur les sorties générées pour inclure également les sorties de modèles de PaLM 2 et Vertex AI Imagen, en plus d'une indemnisation sur les réclamations liées à notre utilisation des données d'entraînement. La couverture d'indemnisation est prévue pour l'API Gemini lorsqu'elle deviendra généralement disponible.

Bienvenue dans l'ère Gemini - commençons à construire​

L'API Gemini est maintenant disponible. Gemini Pro est également disponible sur Google AI Studio, un outil basé sur le web qui aide à développer rapidement des invites. Nous rendrons Gemini Ultra disponible pour certains clients, développeurs, partenaires et experts en sécurité et responsabilité pour des expérimentations et des commentaires précoces avant de le déployer auprès des développeurs et des clients d'entreprise début de l'année prochaine.

Cette version 3.0.0 apporte son lot de nouveautés, mais aussi des améliorations / refonte de certaines de ces fonctionnalités.

Pour y découvrir les principaux changements,

👉 Vous pouvez consulter le changelog de cette version.

👉 Si vous utilisiez déjà la version 2, vous allez devoir migrer vos specifications en V3 et AsyncAPI a pensé à vous en vous proposant un guide de migration.

👉 J'ai moi-même contribué à l'effort en prenant part à une migration du use-case Adeo durant un live avec @lbroudoux de chez Microcks.io :

Pour plus d'informations, vous pouvez consulter le site officiel de l'initiative.

Ambassadeur de l'initiative depuis 2021, je serai ravi de venir vous la présenter lors d'un meetup, d'un BBL ou d'une conférence.

D'ici là, spécifiez bien vos APIs ! 🚀

Oh il est trop mignon​

RedPanda n’est pas qu’une jolie mascotte, c’est aussi un sacré challenger dans le monde du streaming et surtout un challenger d’Apache Kafka. C’est en tout cas son angle d’attaque clairement exposé quand vous lisez le README du projet :

Redpanda is a streaming data platform for developers. Kafka® API-compatible. ZooKeeper® free. JVM free. We built it from the ground up to eliminate complexity common to Apache Kafka, improve performance by up to 10x, and make the storage architecture safer, more resilient. The simpler devex lets you can focus on your code (instead of fighting Kafka) and develop new use cases that were never before possible. The business benefits from a significantly lower total cost and faster time to market. A new platform that scales with you from the smallest projects to petabytes of data distributed across the globe!

Github nous indique que le repo a été créé fin 2020 (https://api.github.com/repos/redpanda-data/redpanda) avec une Stack essentiellement basée sur C++. Depuis, la communauté de contributeurs a grandit et l’offre Cloud et Enterprise est disponible, une sacré roadmap en 3 ans.

Avant de commencer à l’utiliser sérieusement et pour se faire une bonne opinion, il est important de comprendre comment il fonctionne et quels sont les cas d’usages. Pour cela, RedPanda a créé la RedPanda University à l’instar de ce que j’ai déjà pu suivre Chez MongoDB, Redis, Confluent, Neo4j (et que je vous recommande vivement).

Ouvrez votre livre au chapitre 1 : Streaming Basics​

La première partie du cours vous fournira un récapitulatif de ce qu’est un évènement dans les EDA, dans quels cas d’usage nous les utilisons...

Si vous êtes familier des architectures event-driven, ce sera juste un petit récapitulatif. Puis, vous enchainerez avec des patterns de communication : le point-to-point, la dualité event et command, pub/sub, queues… avec un exemple illustré dans le cas de la société Etsy. Le cours propose un "landscape" des plateformes de streaming de données, avec "pros" et "cons" qu’il vous reste à challenger avec votre expérience. Vous pourrez aussi en trouver un ici CNCF Streaming landscape.

La deuxième partie permet d’entrer un peu dans le coeur de la solution. Pour la vision globale, rien de nouveau, des brokers en cluster, des topics, des partitions, du stockage de données brutes agnostiques de tout format. Encore une fois, si vous êtes coutumier d'Apache Kafka passez votre chemin sur les deux premières parties, par contre la 3ème partie vous présentera les composants, la stack et leurs particularités. Une partie de la vidéo est dédiée à la performance, car Redpanda revendique une amélioration x10 en terme de latences et des transactions 6x plus rapides !

Nous tâcherons de tester et de comparer dans des conditions “identiques” plus tard.

D’autres gains de performance sont avancés dans la transformation de données au sein du cluster, puisqu’elle peut être directement réalisée dans la plateforme, là où vous seriez amenés à créer des KStreams ou d’utiliser du Ksqldb. L’autre découverte est le “hardware auto tuner” qui en fonction de votre matériel va permettre de tirer partie au mieux des capacités de la solution.

Côté fiabilité, on trouve la possibilité d’archiver sur le long terme les données avec des connecteurs intégrés vers des solutions Cloud, ce qui évite encore de devoir les gérer soi même.

Si on parle de scalabilité et resilience, elle est comme d’autres, obtenue par le partitionnement et le fait que chaque broker ne soit leader que sur certaines partitions de certains topics, permettant la répartition naturelle de la charge et la tolérance aux pannes (par la replication).

Hands on

Command Line Interface​

Le second cours que je vous conseille permet de mettre vraiment les mains dans la console et de commencer à manipuler un cluster. Je vous passe l’installation, vous pourrez retrouver les détails dans cette documentation et on démarre via la cli "rpk" :

rpk container start -n 3 --verbose
Checking for a local image...
Downloading latest version of redpanda
Pulling image: vectorized/redpanda:v23.2.7
...

et après téléchargement des images nous obtenons très rapidement :

Creating network redpanda
Starting cluster...
Waiting for the cluster to be ready...

Cluster started!
NODE-ID  STATUS   KAFKA-ADDRESS    ADMIN-ADDRESS    PROXY-ADDRESS
0        running  127.0.0.1:64033  127.0.0.1:64027  127.0.0.1:64035
1        running  127.0.0.1:64037  127.0.0.1:64036  127.0.0.1:64024
2        running  127.0.0.1:64038  127.0.0.1:64025  127.0.0.1:64028

L’export en variable de la liste des brokers permet de continuer d’utiliser la CLI et d’interragir avec le cluster :

export RPK_BROKERS="127.0.0.1:64033,127.0.0.1:64037,127.0.0.1:64038"
rpk cluster health
CLUSTER HEALTH OVERVIEW
=======================
Healthy:                     true
Unhealthy reasons:           []
Controller ID:               0
All nodes:                   [0 1 2]
Nodes down:                  []
Leaderless partitions:       []
Under-replicated partitions: []

rpk cluster info
CLUSTER
=======
redpanda.90da6c13-0fb6-4a8e-9357-35ba81e893dc

BROKERS
=======
ID    HOST       PORT
0*    127.0.0.1  64033
1     127.0.0.1  64037
2     127.0.0.1  64038
version: '3.7'

La suite du cours permet de manipuler des topics facilement avec les notions de partition et de réplication que vous connaissez déjà, ou que vous aurez découvert avec le premiers cours.

Ici nous créons deux topics song_plays et song_likes à 6 partitions avec un facteur replication à 1 par exemple.

rpk topic create song_plays song_likes --partitions 6 --replicas 1
TOPIC       STATUS
song_plays  OK
song_likes  OK
rpk topic list --detailed
song_likes, 6 partitions, 1 replicas
      PARTITION  LEADER  EPOCH  REPLICAS
      0          1       1      [1]
      1          0       1      [0]
      2          2       1      [2]
      3          0       1      [0]
      4          2       1      [2]
      5          1       1      [1]

song_plays, 6 partitions, 1 replicas
      PARTITION  LEADER  EPOCH  REPLICAS
      0          1       1      [1]
      1          2       1      [2]
      2          0       1      [0]
      3          0       1      [0]
      4          1       1      [1]
      5          2       1      [2]

Ce que je trouve sympa et simple est la consommation et la production de données avec cette CLI, ici on pousse :

rpk topic produce song_likes
{"song_id": 1234, "event": "like"}
{"song_id": 5678, "event": "like"}
Produced to partition 0 at offset 0 with timestamp 1693340516398.
Produced to partition 0 at offset 1 with timestamp 1693340516398.

Ou en passant un format de clé-valeur dans une chaîne :

rpk topic produce song_likes --format "%k|%v\n"
key1|{"song_id": 1234, "event": "like"}
key2|{"song_id": 5678, "event": "like"}

Et le résultat de la consommation montre la différence entre les deux précédentes productions (la clé) :

rpk topic consume song_likes
{
  "topic": "song_likes",
  "value": "{\"song_id\": 1234, \"event\": \"like\"}",
  "timestamp": 1693340516398,
  "partition": 0,
  "offset": 0
}
{
  "topic": "song_likes",
  "value": "{\"song_id\": 5678, \"event\": \"like\"}",
  "timestamp": 1693340516398,
  "partition": 0,
  "offset": 1
}
{
  "topic": "song_likes",
  "key": "key1",
  "value": "{\"song_id\": 1234, \"event\": \"like\"}",
  "timestamp": 1693340628321,
  "partition": 2,
  "offset": 0
}
{
  "topic": "song_likes",
  "key": "key2",
  "value": "{\"song_id\": 5678, \"event\": \"like\"}",
  "timestamp": 1693340628321,
  "partition": 5,
  "offset": 0
}

La consommation est donc aussi assez simple, vous pouvez choisir la partition que vous souhaitez consommer (ou toutes), l’offset, formater la sortie (comme pour la production)…

Idem pour la manipulation de consumer group, en les spécifiant, en spécifiant leur offset, en effectuant un reset… et en récupérant toutes leurs informations.

Toutes ces commandes, vous me direz que c’est bien sympa, mais au quotidien vous allez probablement préférer une UI et ne pas taper toutes ces commandes. Certes, mais connaître la base c’est aussi sympa et ça peut dépanner quand on ne peut pas brancher d’UI justement, pour la console ce sera sur cette page.

Un peu de code Java​

Cette fois, on sort un peu du terminal et on construit un archétype de projet, je l'ai fait en Java, utilisez Maven ou Gradle pour construire votre projet et ajouter en dépendance le client apache Kafka.

    <dependency>
      <groupId>org.apache.kafka</groupId>
      <artifactId>kafka-clients</artifactId>
      <version>latest</version>
    </dependency>

Un petit Producer issu du repository Github de la Redpanda University et on produit un main Java qui va pousser un message, aussitôt lu via la CLI :

{
"topic": "greetings",
"key": "key1",
"value": "Hello, World!",
"timestamp": 1693856776889,
"partition": 0,
"offset": 0
}

Pas de grand suspens, si je vous dis quand la foulée nous créons un consumer, qui lira ce dernier message.

Consumed record. key=key1, value=Hello, World!

Ce qui peut paraître surprenant, c’est que tout a été fait en utilisant les producers et consumer de la librairie Kafka client. Etant compatible, Redpanda n'a pas réécrit de librairie Java pour lire et écrire dans son cluster.

Passons donc vite à des choses plus sérieuses !

Let’s Start Streaming​

Si vous suivez le 3ème cours (il y en a d’autres), vous allez streamer !

Le panda roux est sujet à inspirer certaines métaphores, on découvre donc qu’à l’instar d’un panda qui surveille les fruits tombés de l’arbre qui coule le long de la rivière, il les dévore dès qu’il peut les attrapper !

La donnée c’est pareil, on doit la consommer fraiche et rapidement.

Avant de parler des transformations plus spécifiques à Redpanda, on découvre ou redécouvre les streams stateless ou stateful dans ce cours, le premier n’a pas besoin de retenir ce qu’il voit et est donc moins gourmand en mémoire tandis que le second aura besoin de retenir des informations pour garder la cohérence (application State, comme avec KStream et sa base RocksDB embedded).

La promesse des Redpanda Data Transform : co-localiser les transformations stateless directement dans le broker. Comment ? En écrivant un peu de NodeJS et en utilisant la CLI pour déployer ces transformations (plus de détails sur le moteur d’exécution et les concepts dans cette page).

Let’s stream avec ce projet support grâce auquel nous allons apprendre à faire une petite transformation de données : masquer un numéro de carte de crédit dans un payload depuis un topic source et le propager vers un autre topic.

Bon, malheureusement pour moi c’est du NodeJS qu'il faut écrire, et ce n’est pas ma tasse de thé, mais c’est purement subjectif à ce niveau du projet (ma version de Node à ce moment était supérieure à celle recommandée par le cours, une issue et un coup de npm plus tard on peut donc déployer notre première transformation).

Les commentaires vous expliquent bien chaque étape et on se rend vite compte que c'est assez simple et parfait pour des transformations de format.

const {
  SimpleTransform,
  PolicyError,
  PolicyInjection
 } = require("@vectorizedio/wasm-api");
 
 // instantiate a class for registering the transform
 const transform = new SimpleTransform();
 
 // subscribe to the source topic, and read from the Earliest offset
 transform.subscribe([["purchases", PolicyInjection.Earliest]]);
 
 // Set the error handling strategy. In this case, we will skip an event
 // if the transform fails
 transform.errorHandler(PolicyError.SkipOnFailure);
 
 // Create a stateless transform function that masks credit card numbers
 const maskCreditCardNumbers = (record) => {
 
  // The record value comes in as a byte string, so deserialize
  // this to a JSON object
  value = JSON.parse(record.value.toString());
 
  // If the record has a card number, mask the card number
  // i.e. 1111222233334444 will become ************4444
  if (value.hasOwnProperty('card_number')) {
    value['card_number'] = value['card_number'].replace(/\d(?=\d{4})/g, "*")
  }
 
  // In order to write back to Redpanda, we need to serialize the new
  // record back into a byte array
  buf = Buffer.from(JSON.stringify(value))
 
  const newRecord = {
    ...record,
    value: buf,
  };
  return newRecord;
 }
 
 // Register the processRecord handler, which will invoke our card masking
 // function on a batch of records
 transform.processRecord((recordBatch) => {
  const result = new Map();
  const transformedRecord = recordBatch.map(({ header, records }) => {
    return {
      header,
      records: records.map(maskCreditCardNumbers),
    };
  });
 
  // Write the result to a new output topic
  result.set("masked", transformedRecord);
 
  // processRecord function returns a Promise
  return Promise.resolve(result);
 });
 
 exports["default"] = transform;
 

Le déploiement via la CLI :

rpk wasm deploy --name mask-card mask-card/dist/main.js

Notre transformation est donc déployée au sein de notre cluster, puisque nous avions déjà cette configuration de faite :

rpk cluster config set enable_coproc true

Là vous vous dites, "j'ai bien lu wasm dans la commande et pourquoi enable coproc ?". Et oui, Redpanda utilise WebAssembly pour la gestion des ces fonctions de transformations et je vous renvoie vers la documentation de Redpanda à ce sujet qui vous expliquera comment une VM tourne sur le leader d'une partition pour traiter ses données à tranformer.

Vous remarquerez (valable en tout casen Janvier 2023), un disclamer indique que ce n'est pas "Production Ready", en tout cas pas conseillé ;-)

rpk topic consume coprocessor_internal_topic --offset start -n 1

➜  mask-card git:(main) ✗ rpk topic list
NAME                        PARTITIONS  REPLICAS
coprocessor_internal_topic  1           1
purchases                   4           1

Maintenant petit instant magique, on produit de la donnée dans le topic et elle apparait masquée dans le topic de sortie :

➜  mask-card git:(main) ✗ rpk topic produce purchases
{"user_id": 123, "card_number": "1111222233334444"}
Produced to partition 3 at offset 0 with timestamp 1694462899860.

➜  mask-card git:(main) ✗ rpk topic list
NAME                        PARTITIONS  REPLICAS
coprocessor_internal_topic  1           1
purchases                   4           1
purchases._masked_          4           1

rpk topic urchases._masked_
{
  "user_id": 123,
  "card_number": "************4444"
  }

Pour supprimer notre transformation rien de plus simple, c’est un remove.

rpk wasm remove mask-card

Un peu de Connect​

Pour le moment, nous nous sommes concentrés sur le coeur de Redpanda et avons eu des interactions de consommation et de production/transformation avec ses brokers. Vous le savez, dans les systèmes d’information, la donnée transite. Elle a une source, elle subit des enrichissements, elle peut croiser des affluents et se déverser à plein d’endroit. Sur son chemin, elle va traverser des couches technologiques différentes, alors comment facilement interconnecter cette hétérogénéité ? C’est là qu’intervient Kafka Connect et les transformations possibles.

Rien de différent non plus par rapport à Apache Kafka ici, je vous laisse découvrir Connect avec le précédent lien.

Et de KStreams​

Puisque les transformations natives au cluster que nous avons vues ou les connectors ne suffisent pas à couvrir tous les usescases possibles avec les données d’un cluster, Kafka Streams permet de construire des applications plus riches qui pourront croiser, joindre des données internes au cluster et réaliser des opérations plus complexes.

Pour plus d’informations, référez vous à la documentation officielle.

Le hands-on de RedPanda dédié au Streams va vous permettre de réaliser une opération assez simple : compter le nombre de commandes par utilisateur qui transitent sur un topic. Un simple groupBy associé à un Count, qui donnera une opération dites “statefull” dans le jargon Kafka. Ce qui va nécessiter de créer un state store pour conserver l’état des données qu’on agrège et compte. Je vous conseille de lire et relire la documentation associée pour bien comprendre le concept (lié à la compaction) et les mécanisme de chargement en mémoire (RocksDB), de haute disponibilité et de tolérance associé.

Ainsi dans notre exemple, la production de ces évènements :

➜ alias rpk="docker exec -ti redpanda-1 rpk"
rpk topic produce purchases --format "%k,%v\n"
user1,purchase_event
user1,purchase_event
user2,purchase_event

va donner ce résultat dans l’application de test

Starting Kafka Streams application
[purchases]: user2, 1
[purchases]: user1, 1
[purchases]: user1, 2
[purchases]: user1, 3

public static Topology build() {
    StreamsBuilder builder = new StreamsBuilder();

    builder.stream("purchases", Consumed.with(Serdes.String(), Serdes.String()))
        // group by the key
        .groupByKey(Grouped.with(Serdes.String(), Serdes.String()))
        // count per key
        .count()
        // convert the table to a stream
        .toStream()
        // print the output
        .print(Printed.<String, Long>toSysOut().withLabel("purchases"));

    return builder.build();
  }

Cette simple topologie nous a permis d’avoir ce résultat. Si vous connaissez Kafka et les Streams, vous voyez donc que c’est scrupuleusement la même chose et vous retrouverez votre State store créé sous forme de topic compact au sein du cluster.

rpk topic list
NAME                                                          PARTITIONS  REPLICAS
local-dev-KSTREAM-AGGREGATE-STATE-STORE-0000000001-changelog  4           1
purchases                                                     4           1

Un use case plus complet​

Pour terminer ce survol de toutes les possibilités/compatibilités de Redpanda, on termine par le cours dédié à un cas d’usage de détection de fraude. Un cas d’usage déjà couvert avec Apache Kafka depuis longtemps et dans de nombreux contextes métier : https://www.confluent.io/fr-fr/use-case/fraud-detection/

Cet exercice est l’occasion de découvrir que Redpanda possède un schéma registry interne au cluster, ce qui diffère de l’écosystème Confluent autour de Kafka : https://docs.confluent.io/platform/current/schema-registry/index.html

Nous configurons donc ensuite les topics nécessaires, créons le connector source à une base Postgres et spécifiquement à la table des “achats”.

docker exec -ti kafka-connect \
    curl -XPUT localhost:8083/connectors/purchases-source/config \
    -H "Content-Type: application/json" \
    -d '
    {
     "connector.class": "io.confluent.connect.jdbc.JdbcSourceConnector",
     "connection.url": "jdbc:postgresql://postgres:5432/root?user=root&password=secret",
     "mode": "incrementing",
     "incrementing.column.name": "id",
     "topic.prefix": "",
     "table.whitelist": "purchases",
     "value.converter": "io.confluent.connect.avro.AvroConverter",
     "value.converter.schema.registry.url": "http://redpanda:8081",
     "transforms": "SetValueSchema,ValueToKey,ExtractKey",
     "transforms.SetValueSchema.type": "org.apache.kafka.connect.transforms.SetSchemaMetadata$Value",
     "transforms.SetValueSchema.schema.name": "com.example.model.Purchase",
     "transforms.ValueToKey.type": "org.apache.kafka.connect.transforms.ValueToKey",
     "transforms.ValueToKey.fields": "credit_card",
     "transforms.ExtractKey.type": "org.apache.kafka.connect.transforms.ExtractField$Key",
     "transforms.ExtractKey.field": "credit_card"
    }'

Le projet Java contient déjà la “topology” et les déclarations de streams qui vont filtrer, compter les opérations sur une fenêtre de temps pour tenter de détecter d’éventuelles fraudes.

Notre Connector source nous a permis de créer un schéma qui est déjà stocké dans le registre.

docker exec -ti redpanda-1 curl localhost:8081/subjects/purchases-value/versions/1 | jq -r '.schema' | jq '.' > src/main/avro/purchase.avsc

On en récupère le contenu en vue d’une compilation avec la génération d’une classe Purchase et de ce qu’il faut pour la sérialiser/déserialiser.

   private int id;
   private java.lang.CharSequence category;
   private java.lang.Double amount;
   private java.lang.CharSequence credit_card;
   private java.lang.Double distance_from_billing_zip;
   private java.time.Instant timestamp;

On créé ensuite en base de données les conditions nécessaires à la levée d’une alerte (à savoir au moins 3 commandes en moins de 60 secondes avec la même carte bancaire). Une alerte est levée et la création d’un nouveau schéma correspondant.

On peut aussi visualiser le topic de travail du state store de notre KStream :

rpk topic list
NAME                                                            PARTITIONS  REPLICAS
_connect-configs                                                1           1
_connect-offsets                                                25          1
_connect-status                                                 5           1
_schemas                                                        1           1
alerts-avro                                                     4           1
alerts-json                                                     4           1
local-dev-0-KSTREAM-AGGREGATE-STATE-STORE-0000000001-changelog  4           1
purchases                                                       4           1

et visualiser notre alerte :

rpk topic consume -n 1 alerts-avro
{
  "topic": "alerts-avro",
  "key": "1111-2222-3333-4444",
  "value": "\u0000\u0000\u0000\u0000\u0002\u0002\u0026high_purchase_count\u0002\u00261111-2222-3333-4444\u0002\ufffd\ufffd\ufffd\ufffd\ufffdb",
  "timestamp": 1695068363227,
  "partition": 1,
  "offset": 0
}

Voilà pour un premier tour de Redpanda si vous n'aviez pas encore creusé cette solution, n'hésitez plus !

Bienvenue sur le blog de zatsit !​

Là où compétences techniques et engagement écologique et sociétal se rencontrent​

Bienvenue sur le blog zatsit, votre espace dédié à la découverte de sujets techniques, mais pas que, rédigés par les collaborateurs. Chez nous, la croissance professionnelle et technologique s'harmonise parfaitement avec un engagement fort envers l'environnement et le bien-être de notre communauté. Nous vous en parlerons au fil des semaines, des mois, des années !

Découvrez des articles​

Au fil de la veille de chacun, des articles viendront fleurir ici. Que ce soit pour une nouvelle solution technique, un retour d'expérience sur un projet ou une passion, les collaborateurs zatsit prendront la plume pour vous chatouiller les neurones !

Les catégories s'étofferont donc pour parler :

• écoconception
• développement mobile, web
• architecture technique
• intelligence artificielle (et moins énergivore on l'espère)
• observabilité et mesure d'empreinte
• ... et bien d'autres encore

Laissez-vous Inspirer par Notre Collectif​

Parcourez nos articles de blog pour entendre les voix de nos collaborateurs, découvrir leurs passions, leurs projets personnels et la manière dont ils contribuent à notre mission commune. Chez zatsit, nous croyons que chaque talent contribue à la prospérité de l'entreprise et de notre écosystème, c'est pourquoi chaque voix compte.

Bonne lecture !