DEV Community: Onepoint

Generating an aerial view of your project with OpenRewrite

Kosmik — Wed, 25 Mar 2026 13:10:52 +0000

Read it in french here

In the previous article, we discussed (well, I wrote, you read) Scanning Recipes when you need complete information to make a decision, or to generate code ex nihilo.

I promised you a little toy at the end... The time has come for the reveal: the Project Graph Generator.

The Need: Mapping Your Code

It’s sometimes difficult to get a global view of the dependencies within your own code. Is this package too tightly coupled to others? What is the central class of my domain? Has my wonderful initial design withstood the ravages of time?

Since OpenRewrite already knows how to build the complete LST of your codebase, it’s not exactly complicated to traverse it to deduce relationships.

This is exactly the goal of the project-graph-generator project: scanning your sources to deduce a dependency graph and produce a simple HTML page using D3.js to display it.

TL;DR;

Oh thou, who doesn’t want to know more, but only wants to play with the graph, go no further than this chapter, you might gain some knowledge!

The project is easily usable via the rewrite-maven-plugin or any other way to trigger an OpenRewrite recipe. Here is the command to launch a complete analysis of your project:

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run \
-Drewrite.recipeArtifactCoordinates=io.github.jtama:project-graph-generator:RELEASE \ ①
-Drewrite.activeRecipes=io.github.jtama.openrewrite.ProjectAerialViewGenerator \
-Drewrite.exportDatatables=true

RELEASE = latest

Once the analysis is complete, the plugin generates a standalone HTML file containing the data AND the visualization. Simply open the class-diagram.html file at the root of your project in your browser to explore the web of your architecture.

You can also pass additional options to filter the nodes according to your needs:

maxNodes=20\ Filters for classes with the highest number of incoming connections.
basePackages=com.mycompany\ Forces the target base package
includeTests=true\ Also include test classes.

To learn more 👉 Here is the project repository. Go ahead, it’s open source, use it, fork it, make issues and pull requests!

The Mechanics: Analysis Without Modification

Under the hood, the tool is based on the ScanningRecipe concept we saw previously. The major difference here is that the generation phase generates HTML, and the *modification* phase (visit) does nothing, nada, zilch. The ~~entire goal~~ of the recipe is concentrated in the first pass: scanning the LST. Well, no, not the goal, rather the intelligence (not the A.I. kind).

It all starts with an accumulator - our famous graph - which will store the classes (Nodes) and their relationships (Links) as the scan progresses:

public static class GraphScanAccumulator {
    public List<Node> nodes = new ArrayList<>(); // ①
    public List<Link> links = new ArrayList<>();

    // ... search methods findNode() and findLink()
}

Did you seriously think I was going to explain this line?

To fill this graph, we will traverse the LST using a JavaIsoVisitor.
First, we identify each component of our architecture by overriding the visitClassDeclaration method. Each new class encountered becomes a "Node":

@Override
public J.ClassDeclaration visitClassDeclaration(J.ClassDeclaration classDecl, ExecutionContext ctx) {
    if (includeTests() || not(isTestClass()).test(getCursor())) { // ①

        if (classDecl.getType() != null) {
            String fqn = classDecl.getType().getFullyQualifiedName();
            graph.findNode(fqn).orElseGet(() -> { // ②
                Node newNode = new Node(fqn, classDecl.getType().getPackageName());
                graph.nodes.add(newNode);
                return newNode;
            });
        }
        return super.visitClassDeclaration(classDecl, ctx); // ③
    }
    return classDecl;
}

We only look at test classes if explicitly requested.
We use our graph accumulator to register the current class if it hasn’t been seen already.
We don’t forget to call super so that the visitor continues to descend into the tree. If and only if the class is of interest to us, otherwise, we don’t waste our time.

Next, we must weave the web. How do we know that class A depends on class B? We simply capture type usages (method calls, fields access, instantiations). For example, here’s how we proceed for method invocations:

@Override
public J.MethodInvocation visitMethodInvocation(J.MethodInvocation method, ExecutionContext ctx) {
    var mi = super.visitMethodInvocation(method, ctx); // ①

    JavaType.FullyQualified targetType = mi.getMethodType() != null ? mi.getMethodType().getDeclaringType() : null; // ②

    if (targetType != null) {
        addLink(targetType); // ③
    }
    return mi;
}

Let the visitor visit.
Extract the type information (JavaType) carried by the invoked method to know which class it belongs to. The type can be null, particularly if OpenRewrite failed to determine it.
Invoke the addLink method.

The addLink method contains all the logic allowing us to determine if the targetType interests us, that is to say if it is part of the target packages. If so, we create a new link or strengthen an existing one.

The same logic is obviously applied to member references, class fields, constructor invocations, etc.

This is the beauty of OpenRewrite’s model: the LST is already perfectly typed by the compiler during parsing. We don’t need to guess who an invoked method belongs to, the type information tells us with certainty.

Going Further: Raw Export with Datatables

Generating an HTML page is nice. But what if you want to cross-reference this data, render it yourself in a tool like Gephi, or even provide it as context to an LLM to audit your architecture?

This is where OpenRewrite’s Datatables come in. In addition to the view, project-graph-generator can export metadata in the form of easily usable CSV files:

*target/rewrite/datatables/io.github.jtama.openrewrite.model.NodesReport.csv *\ Contains all the classes found with their package and their number of incoming/outgoing connections.
*target/rewrite/datatables/io.github.jtama.openrewrite.model.LinksReport.csv *\ Exhaustive list of links between classes with an associated weight.
*target/rewrite/datatables/io.github.jtama.openrewrite.model.JavaSourceFileExcludedReport.csv *\ All classes that were excluded from the final result (often due to package filtering).

Now, it’s your turn. Run the scanner on your legacy, and contemplate (or be frightened by) the extent of the web!

P.S.: As you may have noticed, this plugin is distributed on Maven Central (io.github.jtama:project-graph-generator). If you’re wondering how to easily automate the entire publication chain without tearing your hair out, I recommend you take a look at my JReleaser tutorial.

TNT 2026

Yann Schepens — Tue, 24 Feb 2026 08:01:36 +0000

On ne le dira jamais assez, Touraine Tech, c’est un peu la madeleine de Proust de pas mal de conférenciers et conférencières. Il y a un côté "retour sur les bancs de l’école", ce qui est littéralement le cas, l’événement se déroulant dans les locaux de la Faculté des Sciences et Techniques de Tours.

3ème édition pour moi cette année. Après avoir parlé d’ESI et d’Infra as Code, j’ai discuté de veille techno avec un nouveau format pour moi : le Quickie.

Cette année, comme l’année dernière, nous débarquons avec une délégation onepoint. Trois Bordelais et trois Nantais. Un peu moins que les années précédentes, mais disons que ce sont les meilleurs…

Petit rappel sur TNT

Cette conférence généraliste de l’IT, se déroulant sur deux jours, est un très bon endroit pour les primo-speakers comme pour les plus expérimentés. La plupart des speakers connaissent TNT ou, du moins, des membres de l’équipe d’organisation. C’est un point de rendez-vous annuel pour nombre d’entre eux, dans une ambiance toujours très bon enfant, mais très studieuse. Ici, on parle, on rigole et on apprend.

Trêve de bavardages, allons découvrir ces deux jours.

L'évènement

TNT en est à sa 8ème édition. Il s’est déroulé pendant quelques années dans les locaux de Polytech’Tours mais, vu son succès, il investit maintenant la Faculté des Sciences. Les étudiants aident l’équipe organisatrice tout au long de l’événement, une particularité plutôt cool. Que ce soit pour l’installation, la logistique ou la gestion de la captation, ils sont partout. Bravo à eux, ce n’est pas facile de gérer tout un tas de développeurs en vadrouille.

L’équipe organisatrice est composée de beaucoup de speakers et d’habitués des conférences et meetups, et ça se voit. Que ce soit au niveau de la planification, de la communication ou de la réactivité, l’événement est cadré, efficace et très professionnel, avec un accent important mis sur la bonne humeur et la bienveillance. C’est un confort incroyable pour tout le monde : speakers, sponsors et public.

500 participants
260 soumissions au CFP
Diffusion en direct sur YouTube
Atelier d’initiation aux premiers secours pendant l’événement

Le lieu

La Faculté des Sciences de Tours n’est plus toute jeune, et ça se voit. Par contre, elle a l’avantage de pouvoir accueillir sans problème cinq tracks dans cinq amphithéâtres. C’est une école, elle est donc bien équipée pour les conférences.

Les lieux de passage peuvent être un peu étroits, surtout avec les stands, mais cela donne une petite impression de "retour à l’école" particulièrement drôle. Un barnum est aussi installé à l’extérieur pour les repas et le café. Cet endroit, un peu à l’écart, se prête bien au papotage sans gêner le passage entre les conférences.

Les soirées

Autour de TNT, trois soirées : une "avant", une pour les speakers entre les deux jours, et une "après". Je ne peux pas aller à celle d'après (il faut bien rentrer à la maison !), mais je ne raterais pour rien au monde les deux premières.

Cette année, comme l’an dernier, la première soirée s’est faite au Delirium Café. On ne va pas se mentir, le monde de l’IT et les brasseries ont une affinité particulière. Encore une occasion de revoir les connaissances avant de plonger dans le bain.

Pour l’entre-deux, direction le Cubrik, dans le centre de Tours. Excellente soirée en très bonne compagnie. Cela faisait longtemps que je n'étais pas parti en conférence et ça m’a fait plaisir de revoir des têtes connues.

C’est bien de faire la fête, mais l’important, ce sont les conférences !

Conférences

Keynote d'ouverture "Tech vs bots, débuggons la démocratie"

Clément Hammel-Cazenave CEO d'Agoratlas

Qui de mieux pour ouvrir une conférence d'IT que le boss d'une entreprise spécialisée dans l'analyse de ce qu'il se passe dans les réseaux sociaux ; et plus précisement sur la notion de l'influence des réseaux sociaux et de manipulation des informations que l'on trouve dessus sur nos démocraties.

Clément nous explique comment, techniquement et visuellement, ils font leur analyse et la génération des graphs (Méthode de Louvain). Je vous passe les détails, mais on constate très clairement la notion de récupération politique dans les communications sur les réseaux. Il appuie ces analyses avec des exemples assez importants, tel que les échanges entre Trump et Zelensky ou la crise des agriculteurs. On constate assez rapidement la création de faux comptes, la duplication de contenu et les différentes stratégies d'influences.

En partant de ces états de fait, Clément prend de la hauteur et amène la notion de guerre de l'information et des usages par les différents états.

Bref, le sujet est passionnant, autant techniquement que sur l'importance que ça a dans nos quotidiens.

Pour conclure, quelques éléments que je souhaite mettre en avant : Viginum, Gephi, D3lta pour la tech et les organismes. Et enfin, Cadrer, Detecter, Réagir, Collaborer et SORTEZ DE X (Twitter).

Merci beaucoup Clément.

Onboarding 2.0 : Réinventer l'intégration des devs

Hafsa ELMAIZI

Pourquoi j'y vais : Avec 15ans d'expérience derrière-moi, je suis généralement côté intégration des équipes, ma vision est donc biaisée sur la façon dont son vécu les onboarding, surtout avec les plus juniors d'entre nous. Une piqure de rappel, et peut-être une nouvelle approche, me fera du bien.

Mon avis : Hafsa fait un constat que je partage : la plupart des onboarding sont nuls et mal faits. Il manque le materiel, les accès, une personne vous accueille pendant 1 heure et retourne à ces occupations, vous laissant là, au milieu du bureau, comme une ame en peine.

Elle propose donc une structure, un plan, sur plusieurs mois permettant d'améliorer ce process, qui n'est pas qu'une formalité.

Au travers différentes scénettes, Hafsa décrit chacune de ces étapes et les granularités et objectifs attendus. De l'intégration, la découverte de la culture d'entreprise, la création de lien et comment devenir performant, tout y passe.

Que ce soit par les outils ou les intervenants, l'objectif de cette intégration est d'avoir un nouveau collaborateur en confiance, autonome et évidemment performant.

Je vous conseille vivement d'aller voir cette conférence, qui au-delà de son côté "plein de bons sens", est très "terrain" et rapidement applicable.

Merci Hafsa

Redécouvrir PHP : pratiques modernes au-delà de l’héritage

Horacio Gonzalez (LostInBrittany)

Pourquoi j'y vais : Parce que PHP, j'aime ce langage et même si je n'en fais plus régulièrement, ça reste mon langage de prédilection. Je veux connaitre les évolutions.

Mon avis : Ouuuuuuuuuuuuuuiiiiiiiiiiiii, enfin, merci ! Ce sujet était dans mon backlog de conférence depuis quelques années, mais je n'ai jamais pris de temps de l'aborder. Et Horacio le fait extrêmement bien.

Il reprend toutes les horreurs encore évoquées sur PHP aujourd'hui, se basant sur un PHP de... 2004. Il va falloir grandir un peu et se renseigner. Il évoque le fait qu'à de "se faire bully" par les autres développeurs, les développeurs PHP ont créé leur propre écosystème de conférence, de plateforme, etc. Clairement aussi qualitive que les plateformes généralistes.

Il revoit toutes les évolutions du langage pour arriver aujourd'hui, et depuis quelques années en réalité, à un langage, des frameworks et des pratiques qui ressemblent peu ou prou à ce que propose l'ensemble des langages dit moderne.

Il passe aussi sur l'omniprésence de ce langage et de son ecosystème sur Internet et les plateformes que nous utilisons au quotidien. Tout en montrant les évolutions présentes et à venir autour du langage.

Et merci Horacio de bien faire la distinction entre Wordpress et le reste de l'écosystème PHP, on a pas la même démarche, car pas les mêmes besoins et/ou envies.

J'en entends certains se dire : "impossible, c'est du PHP", ces gens sont nulles et incompétents pour un langage nul et inutile. Vous savez quoi, restez dans vos dogmes ou allez vous renseigner un minimum (d'ailleurs, faites attention, on utilise plus le franc maintenant, on est passé à l'euro).

Ca fait du bien de voir ce genre de sujet arrivé dans des conférénces généralistes.

Bravo !

Title, ce faux ami de l'accessibilité

François-Xavier Lair

Pourquoi j'y vais : Parce que FX déjà, ensuite le HTML, c'est juste la base de ce que nous développons et qui est visible par les utilisateurs, TOUS les utilisateurs.

Mon avis : FX que je vois sortir en courant de la salle, oubli de télécommande, puis qui se rend compte, au bout de 3 min (sur un quickie), qu'il n'est pas sur les bons slides et le son qui ne fonctionne pas, ca n'a pas de prix.

Sinon, bonne (re)mise au point sûr d'usage de l'attribut title, les impacts sur l'accessibilité et surtout les alternatives à title pour les tooltips et les fonctionnalités de title. Découverte pour moi de l'attribut popover qui est vraiment intéressant.

FX est toujours un très bon speaker, précis et efficace, d'autant plus qu'il imite hyyyyper bien le lecteur d'écran (et oui pas de son).

Merci FX !

J'ai packagé mon application en image Docker, et maintenant ?

Aurélie Vache

Pourquoi j'y vais : Parce que Aurélie. Et surtout comment assurer la sécurité dans notre chaine de fabrication.

Mon avis : Tiens ?! Aurélie sur un sujet tech, mais oui !

Puis pas n'importe quel sujet : la mise en place de la norme SLSA dans le cas des réglementations CRA, NIS2, etc.

Via cette conférence, Aurélie nous réexplique les failles potentielles sur une chaine de fabrication et la raison d'être du SLSA, et son côté très obscur d'ailleurs. Les notions de SBOM, VEX, In-toto, PURL nous sont expliqués ainsi que leur usage, mais le plus intéressant est la mise en pratique.

En effet, elle met en œuvre, en live, les mécanismes de sécurisation de la chaine de fabrication de son image docker. Elle nous montre comment utilisez chacun des outils (et il y en a beaucoup), en nous conseillant sur les usages, et ce, de bout en bout de la chaine de fabrication.

A son habitude, l'explication est claire et efficace. Pour m'être confronté au sujet, j'aurais préféré avoir vu cette conférence (ou avoir une petite Aurélie sur l'épaule) avant de m'y lancer.

Au-delà d'être une excellente approche 360 autour du sujet, on repart avec une nouvelle boite à outils en sachant comment et à quoi sert chacun de ces outils.

Merci Aurélie !

Fatigués de la POO ? Passer à la DOP !

Jérôme Tama

Pourquoi j'y vais : Parce que Jérôme (oui, je choisis aussi en fonction de mes connaissances), En tant qu'adepte de la conception logicielle sous toutes ses coutures, forcement, la notion de DOP m'intrigue.

Mon avis : Jérôme et les démos live, on voit qu'il aime ça. Comme à son habitude, il prend un bout de code déjà existant et le reprend pour apporter les concepts.

Il nous remontre comment utiliser correctement la POO, en cherchant à modéliser le réel. Là où sa conférence est particulièrement intéressante, c'est qu'il va s'appuyer sur les capacités avancées, ou non, de son langage pour arriver à ses fins.

On arrive à un code élégant et efficace, il nous emmène à l'état de l'art de la conception et du langage, c'est un exemple.

Merci Jérôme.

Un jardin sur sol vivant connecté, pourquoi et comment ?

Alexandre Delegue

Pourquoi j'y vais : L'informatique est censé aider les gens, quoi de plus utile qu'un jardin ?.

Mon avis : Un talk sur le jardinage, sérieusement. Alexandre reprend les différents types d'agriculture, les mécanismes artificiels ou naturels pour faire pousser des plantes, l'impact de l'homme de manière très concrète sur la terre (avec un t minuscule).

On parle de sol vivant, de grandes cultures, de serres tropicales et on finit avec un peu de domotique dans le jardin d'Alexandre qui nous explique comment il compte faire son jardin en s'appuyant sur ce qu'il a lu et un peu de tech.

C'était ... rafraichissant :)

Plus sérieusement, j'ai beaucoup aimé, de part à ma curiosité naturelle, ça ne parle vraiment pas de tech, hormis un peu à la fin. Et encore.

Merci Alexandre :)

Open-source : Pourquoi ? Comment ?

Julien Deniau

Pourquoi j'y vais : Le titre. Sans l'opensource, notre métier serait bien différent. Il est important de contribuer, je veux découvrir cette approche.

Mon avis : Première fois que je vois Julien, et j'ai apprécié le personnage et l'approche. Il rappelle que tout le monde de l'IT tient sur le travail de quelques personnes... Que même nous, nous ne connaissons pas.

Il nous coince avec un quizz sur les maintainer/créateurs de Curl, PHP, Java. On ne connait personne. Tristesse.

Ensuite, s'envient la discussion sur les motivations à faire de l'opensource. L'argent, la notoriété, tester des trucs, pas vraiment. Par contre, développer de la connaissance oui ! Et quelques trucs cools, comme le fait de recevoir des remerciements, mais c'est réellement rare.

Il nous donne quelques conseils pour se lancer dans l'opensource et rappelle, à juste titre, que l'opensource, ce n'est pas que produire du code. C'est aussi rapporter des bugs, proposer des évolutions, écrire des articles, etc.

Deux choses importantes à ce sujet : l'IA pompe tout l'opensource, à vous d'en tirer vos conclusions. Et surtout, 1,5% de femmes dans l'opensource.

Merci Julien pour tous ces messages !

Keynote de fermeture

Jean-François Garreau

Speechless : Extra

La confrontation entre 4 speakers chevronné(e)s, qui ne connaissent pas le sujet, ni les slides et qui n'en sont clairement pas aidé. C'est toujours exceptionnels. Je ne sais pas si ce sera capté, mais si vous voulez voir du talent à l'état pur et passer un bon moment de rigolade, allez-y.

Et toujours aussi malicieusement animé par Jean-François, qui manipule diaboliquement le public et les speakers.

Keynote ouverture : Gray hat, Black Hat, Users, Employés

Mikael Robert, Yohann Boyer, Benjamin Chouraqui (pas là, mais un peu là)

Mon avis : Découverte pour moi d'un nouveau réseau social : Yubo. Encore un truc de jeune. Et surtout, encore un endroit où la cybersécurité est importante. Mais pas de la façon dont on l'aborde généralement.

Mikaël et Yohann nous expliquent qu'aujourd'hui, le hacker, ce n'est pas seulement la personne hypercalé en tech. C'est aussi l'ado qui sait se servir de son téléphone et comprend le fonctionnement d'une appli pour en contourner l'usage. Et l'IA lui permet d'aller vite et plus loin.

Ils reprennent les notions de Black/White/Grey hat et le fait qu'aujourd'hui, ces termes sont beaucoup plus flous. Ils présentent différents types d'attaque, inédites pour la plupart, et comment ils arrivent à les contrer. Au passage, il nous redonne les bonnes pratiques pour gérer efficacement les failles de sécurité, sans se précipiter et pour trouver les bonnes solutions.

Cette keynote est une excellente keynote, elle remet les pieds sur Terre, est très pratique et, je pense, lucide la réalité.

Merci, j'ai hate d'avoir le replay pour le diffuser.

Serveurs MCP au-delà des bases : bonnes pratiques, choix de conception et leurs conséquences

Horacio Gonzalez

Pourquoi j'y vais : J'ai suivi Jérôme. Et de toute façon, va falloir que je me renseigne un peu sur les MCP

Mon avis : Avec beaucoup de slides, Horacio revient sur les problématiques liés à la communication entre une IA et nos API plus classique. Il développe donc le principe des serveurs MCP et leur fonctionnement. Son idée, avec laquelle je suis en phase, est que nous fait de l'API first, et maintenant, il faudra aussi avec un serveur MCP automatiquement pour pouvoir interconnecter l'ensemble du monde de l'IT.

Nous ne sommes plus à l'étape de la découverte pour les MCP, mais à l'étape des bonnes pratiques. Il en liste d'ailleurs une bonne quantité qu'il met à disposition sur son dépôt Github (je vous laisse aller les chercher sur github, son pseudonyme est LostInBrittany).

Merci Horacio, c'était très clair. Dès que la vidéo sort, jetez-vous dessus, il vous apprendra des choses.

Tricher pour apprendre : 30 minutes par jour pour rester curieux dans nos métiers de la tech

Yann Schepens

Pourquoi j'y vais : Ai-je besoin de répondre à cette question ?

Mon avis : MON PREMIER QUICKIE ! Ben ça s'est bien passé, je suis assez content. Mais c'est vrai que le format est vraiment particulier. Passer d'un deepdive à un quicky, ça fait bizarre.

Un passage à 13h avec pas mal de monde (merci à Estelle Landry d'ailleurs qui a poussé les gens à venir me voir), dont quelques guests stars :)

Pas mal de bons retours, juste après ou dans les couloirs. Pour un sujet hors tech, c'est toujours agréable.

Local-first et sync-engines, l'architecture du futur ?

Benjamin Legrand

Pourquoi j'y vais : Parce que Benjamin. Même si je ne comprends pas tout, j'apprends toujours des super trucs

Mon avis : Je n'ai pas pris de note. Mais c'était bien. Plus sérieusement, Benjamin nous ramène un peu sur une logique qui devrait être standard, pourquoi dépendre d'un système moins stable que notre propre système de stockage ? Et d'un point de performance, ce n'est quand même pas la même chose non plus.

Il amène aussi un second point qui en découle, le stockage de données décentralisé qui modifie grandement la façon d'aborder la persistance des infos.

Il propose plusieurs solutions existantes, notamment sur les aspects synchronisations et pose l'ensemble des avantages et inconvénients liés à ces mécaniques.

Merci Benjamin, j'adore tes conférences, elles n'ont jamais l'air vraiment fini :P

Le mot de la fin : Une édition "Grand Cru" (Par Gemini)

(J'ai relu et je suis d'accord quand même)

On repart de cette 8ème édition de Touraine Tech avec la tête bien pleine et le sourire aux lèvres. Si la faculté des sciences de Tours nous offre ce petit côté "nostalgie des bancs de l'école", le contenu, lui, était résolument tourné vers l'avenir.

Cette année 2026 marque un tournant dans nos préoccupations de développeurs et de tech leads :

La sécurité n'est plus une option : Entre la sécurisation des chaînes de fabrication (SLSA) d'Aurélie, les enjeux de modération sur les réseaux sociaux et la lutte contre les bots, nous sommes les nouveaux gardiens de la confiance numérique.
L'humain au cœur du code : Que ce soit par un onboarding soigné, la redécouverte de la noblesse de langages comme PHP ou l'investissement dans l'open-source, notre métier est avant tout une affaire de transmission et de passion.
L'IA devient concrète : Avec les serveurs MCP, nous sortons du gadget pour entrer dans l'ère de l'industrialisation des agents intelligents.

Un immense bravo à toute l'équipe d'organisation et aux étudiants pour la logistique impeccable. C'est toujours un plaisir de croiser les copains, de refaire le monde au Delirium ou au Cubrik, et de voir la délégation Onepoint porter haut nos couleurs.

Une pensée particulière pour ceux qui ont fait vibrer ces deux jours par leur expertise ou leur grain de folie : Aurélie, Estelle, Jean-François, Nathan, Ambre, Jérôme, Benjamin, FX, Thierry, Stéphane et Fanny. C'est grâce à des speakers et des organisateurs de cette trempe que la communauté tech reste aussi soudée et bienveillante.

Touraine Tech reste, année après année, ce rendez-vous incontournable où l'on parle, on rigole et, surtout, on apprend énormément.

À l'année prochaine, Tours !

Multi-Agent Platform with A2A, Python, Strands & AWS AgentCore

Meidi Airouche — Wed, 14 Jan 2026 08:39:44 +0000

A single RAG agent is easy to ship.

But the moment you need multiple domains (HR, IT, …), different knowledge sources, and clean ownership boundaries, a single “do‑everything” agent turns into:

an unmaintainable prompt,
a tangled toolset,
and a retrieval strategy that mixes unrelated documents.

This post shows a production-shaped approach:

HR Agent: RAG over HR documents (AWS Knowledge Base ID configured via env)
IT Agent: RAG over IT documents (different KB ID)
Orchestrator Agent: routes queries by calling HR/IT agents over A2A, then synthesizes the final answer

All three are deployed as AgentCore Runtime apps : each handler is a BedrockAgentCoreApp entrypoint.

Strands Agents is a Python SDK for building LLM-based production-ready agents as first-class software components.
It abstracts prompt management, tool invocation, and agent-to-agent communication, enabling to compose complex agent systems without hard-coding control flows or glue logic.

What we are building

Components

HR Agent
- Strands Agent
- Tool: strands_tools.retrieve
- Config: KNOWLEDGE_BASE_ID (HR KB)
- Exposed as an A2A endpoint via AgentCore Runtime
IT Agent
- Same as HR agent
- Config: KNOWLEDGE_BASE_ID (IT KB)
Orchestrator Agent
- Strands Agent
- Tools: ask_hr_agent, ask_it_agent (A2A client calls)
- Config: HR_AGENT_URL, IT_AGENT_URL
- Decides routing automatically (tool choice) and synthesizes a final answer

Runtime request flow

User sends a question to the Orchestrator (AgentCore Runtime endpoint)
Orchestrator LLM decides whether to use:
- ask_hr_agent()
- ask_it_agent()
- or both
Orchestrator calls the specialized agent(s) via A2A
Specialized agent uses retrieve tool (RAG) against its Knowledge Base
Orchestrator produces a final, human‑readable answer

1 — Configuration (env vars)

This architecture is intentionally configuration-first. No hardcoded URLs or KB IDs.

Knowledge bases are created with S3 Vector base but outside of this topic since it's easy to create with 5 clics. Just collect the IDs once created.

The retrieve tool provided by strands_tools is automatically configured at runtime using KNOWLEDGE_BASE_ID, which AgentCore resolves to the correct vector store and injects into the retrieval tool execution.

HR Agent env

KNOWLEDGE_BASE_ID The Knowledge Base ID for HR content.

IT Agent env

KNOWLEDGE_BASE_ID The Knowledge Base ID for IT content.

Orchestrator env

HR_AGENT_URL

A2A endpoint for the HR Agent (for example, an AgentCore Runtime service URL).
IT_AGENT_URL

A2A endpoint for the IT Agent.
AWS_REGION (optional)

Defaults to eu-central-1 in the handler.

2 — HR Agent handler (AgentCore Runtime + RAG)

This is the complete HR agent handler.

Key design choices:

Lazy initialization: create the Strands agent only once per runtime container
Single tool: retrieve
Strict behavior: if retrieval doesn’t find anything relevant, say so

"""
HR Agent handler for AgentCore Runtime deployment with A2A support.

Requirements: 1.1, 1.2, 1.4
"""

import os
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Configuration
KNOWLEDGE_BASE_ID = os.getenv("KNOWLEDGE_BASE_ID", "")
os.environ["KNOWLEDGE_BASE_ID"] = KNOWLEDGE_BASE_ID

HR_SYSTEM_PROMPT = """
You are an expert HR assistant. You answer questions related to human resources,
HR policies, leave, benefits, recruitment, and people management.

Use the retrieval tool to search the HR knowledge base.
If you cannot find relevant information, clearly state it.

Always respond in a professional and concise manner.
"""

# Lazy agent initialization
_hr_agent = None


def get_hr_agent():
    """Lazy load HR agent."""
    global _hr_agent
    if _hr_agent is None:
        from strands import Agent
        from strands_tools import retrieve

        _hr_agent = Agent(
            tools=[retrieve],
            system_prompt=HR_SYSTEM_PROMPT
        )
        logger.info("HR agent initialized")
    return _hr_agent


def handle_request(prompt) -> str:
    """Handle HR agent requests."""
    try:
        prompt_str = str(prompt)
        agent = get_hr_agent()
        response = agent(prompt_str)
        return response.message
    except Exception as e:
        logger.error(f"HR agent error: {e}")
        return f"Erreur agent RH: {str(e)}"


# For AgentCore Runtime with A2A
try:
    from bedrock_agentcore.runtime import BedrockAgentCoreApp
    app = BedrockAgentCoreApp()
    logger.info("HR BedrockAgentCoreApp initialized")


    @app.entrypoint
    def handler(prompt: str) -> str:
        logger.info(f"HR received: {prompt[:100]}...")
        return handle_request(prompt)
except ImportError as e:
    logger.warning(f"bedrock_agentcore.runtime not available: {e}")
    app = None

Why `os.environ["KNOWLEDGE_BASE_ID"] = KNOWLEDGE_BASE_ID`?

Some tooling layers (including retrieval integrations) resolve configuration directly from process environment. By forcing it into os.environ, you ensure:

consistent behavior in local runs
consistent behavior in AgentCore Runtime containers

What “RAG” means here

In this handler, RAG is not manual (no explicit vector DB queries in your code).
Instead, the Strands agent uses the retrieve tool:

the LLM decides when to call retrieve
the tool pulls relevant chunks from your Knowledge Base
the response is generated with that context

3 — IT Agent handler (AgentCore Runtime + RAG)

This is the complete IT agent handler.

Same architecture as HR:

lazy init
tool = retrieve

"""
IT Agent handler for AgentCore Runtime deployment with A2A support.

Requirements: 2.1, 2.2, 2.4
"""

import os
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Configuration
KNOWLEDGE_BASE_ID = os.getenv("KNOWLEDGE_BASE_ID", "")
os.environ["KNOWLEDGE_BASE_ID"] = KNOWLEDGE_BASE_ID

IT_SYSTEM_PROMPT = """
You are an expert IT assistant. You answer questions related to IT,
systems, software, technical support, cybersecurity, and infrastructure.

Use the retrieval tool to search the IT knowledge base.
If you cannot find relevant information, clearly state it.

Always respond in a professional and concise manner.
"""

# Lazy agent initialization
_it_agent = None


def get_it_agent():
    """Lazy load IT agent."""
    global _it_agent
    if _it_agent is None:
        from strands import Agent
        from strands_tools import retrieve

        _it_agent = Agent(
            tools=[retrieve],
            system_prompt=IT_SYSTEM_PROMPT
        )
        logger.info("IT agent initialized")
    return _it_agent


def handle_request(prompt) -> str:
    """Handle IT agent requests."""
    try:
        prompt_str = str(prompt)
        agent = get_it_agent()
        response = agent(prompt_str)
        return response.message
    except Exception as e:
        logger.error(f"IT agent error: {e}")
        return f"Erreur agent IT: {str(e)}"


# For AgentCore Runtime with A2A
try:
    from bedrock_agentcore.runtime import BedrockAgentCoreApp
    app = BedrockAgentCoreApp()
    logger.info("IT BedrockAgentCoreApp initialized")


    @app.entrypoint
    def handler(prompt: str) -> str:
        logger.info(f"IT received: {prompt[:100]}...")
        return handle_request(prompt)
except ImportError as e:
    logger.warning(f"bedrock_agentcore.runtime not available: {e}")
    app = None

Why separate agents instead of one big agent with two KBs?

Because the separation buys you:

independent prompts
independent retrieval scopes (no “HR policy” leaking into IT answers)
independent deployment/scaling
simpler evaluation (HR answers vs IT answers)

4 — Orchestrator handler (AgentCore Runtime + A2A tools)

Now the interesting part: the orchestrator.

Your orchestrator is a Strands agent with two tools:

ask_hr_agent
ask_it_agent

Those tools are wrappers around an A2A client call.

Orchestrator key behaviors

It does not use retrieve itself
It delegates to specialized agents
It may call both if needed

"""
Orchestrator Agent handler for AgentCore Runtime deployment.

Uses Strands Agent with HR/IT agents as tools - the model decides routing.

Requirements: 3.1, 3.2, 3.3, 3.4, 3.5
"""

import os
import logging
import asyncio
from typing import Any

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Configuration
AWS_REGION = os.getenv("AWS_REGION", "eu-central-1")
HR_AGENT_URL = os.getenv("HR_AGENT_URL", "")
IT_AGENT_URL = os.getenv("IT_AGENT_URL", "")

# Lazy initialization
_orchestrator_agent = None


async def _call_a2a(url: str, query: str) -> str:
    """Internal A2A call."""
    from a2a.client import A2AClient

    async with A2AClient(url) as client:
        response = await client.send_message(query)
        if hasattr(response, 'message') and response.message:
            for part in response.message.parts:
                if hasattr(part, 'text'):
                    return part.text
        return str(response)


def ask_hr_agent(query: str) -> str:
    """
    Ask the specialized HR agent.

    Use this tool for questions about:
    - HR policies, leave, payroll
    - Recruitment, hiring, contracts
    - Training, performance reviews
    - Benefits, insurance, retirement
    - Remote work, absences
    """
    if not HR_AGENT_URL:
        return "Erreur: Agent RH non configuré"

    try:
        return asyncio.run(_call_a2a(HR_AGENT_URL, query))
    except Exception as e:
        logger.error(f"HR agent error: {e}")
        return f"Erreur agent RH: {str(e)}"


def ask_it_agent(query: str) -> str:
    """
    Ask the specialized IT agent.

    Use this tool for questions about:
    - Computers, software, support
    - Network, Wi‑Fi, VPN, internet
    - Passwords, accounts, access
    - Security, antivirus
    - Email, Teams, apps
    """
    if not IT_AGENT_URL:
        return "Erreur: Agent IT non configuré"

    try:
        return asyncio.run(_call_a2a(IT_AGENT_URL, query))
    except Exception as e:
        logger.error(f"IT agent error: {e}")
        return f"Erreur agent IT: {str(e)}"


ORCHESTRATOR_SYSTEM_PROMPT = """You are an orchestrator assistant for employees.

You have access to two specialized agents:
- HR Agent: for all human resources questions (leave, payroll, contracts, training, etc.)
- IT Agent: for all IT-related questions (software, hardware, technical support, etc.)

Analyze each question and use the appropriate agent(s) to answer.
If a question spans both domains, consult both agents.

After receiving the responses, synthesize a clear and complete final answer.
"""


def get_orchestrator_agent():
    """Get or create the orchestrator agent with HR/IT tools."""
    global _orchestrator_agent
    if _orchestrator_agent is None:
        from strands import Agent

        _orchestrator_agent = Agent(
            tools=[ask_hr_agent, ask_it_agent],
            system_prompt=ORCHESTRATOR_SYSTEM_PROMPT
        )
        logger.info("Orchestrator agent initialized with HR/IT tools")
    return _orchestrator_agent


def handle_request(prompt) -> str:
    """Handle orchestrator requests."""
    try:
        prompt_str = str(prompt)
        agent = get_orchestrator_agent()
        response = agent(prompt_str)
        return response.message
    except Exception as e:
        logger.error(f"Orchestration error: {e}")
        return f"Erreur: {str(e)}"


# For AgentCore Runtime
try:
    from bedrock_agentcore.runtime import BedrockAgentCoreApp
    app = BedrockAgentCoreApp()
    logger.info("Orchestrator BedrockAgentCoreApp initialized")


    @app.entrypoint
    def handler(prompt: str) -> str:
        return handle_request(prompt)
except ImportError as e:
    logger.warning(f"bedrock_agentcore.runtime not available: {e}")
    app = None

Why implement HR/IT calls as tools?

Because it makes routing model-driven instead of hard-coded.

You’re giving the orchestrator:

a system prompt describing the domains
tool docstrings that describe when to use them
a stable interface (ask_hr_agent(query) -> str)

The LLM chooses the right tool(s), and you keep your Python logic minimal.

5 — A2A call parsing

A2A responses often come as structured messages with parts.
The parsing strategy is resilient:

if hasattr(response, 'message') and response.message:
    for part in response.message.parts:
        if hasattr(part, 'text'):
            return part.text
return str(response)

Why this matters:

You don’t assume a single “text blob” response
You gracefully fallback to str(response)

6 — Lazy initialization (production detail that matters)

All three handlers use lazy init (_agent = None).

Why it’s important in AgentCore Runtime:

cold start cost is paid once per container
subsequent requests reuse the same agent instance
lower latency and less overhead

This is the kind of detail that separates a demo from something you can run for real users.

7 — How routing actually happens

You don’t have if "vpn" in query: ....

Instead:

The orchestrator receives the question
It decides which tool(s) to call based on system prompt + tool descriptions
It synthesizes a final answer

Example behaviors:

HR-only question → calls ask_hr_agent
IT-only question → calls ask_it_agent
Mixed question → calls both, then merges

8 — Failure modes and debugging

Your code already includes the essentials:

INFO logging
explicit “not configured” messages
tool-level error handling

Common issues:

Missing URL

If HR_AGENT_URL is empty:

ask_hr_agent returns Error: HR agent not configured

Network/A2A issues

If A2A fails:

error is logged
tool returns Error HR agent: ... / Error IT agent: ...

The orchestrator can still produce a partial answer if only one agent fails.

9 — Practical hardening ideas (optional)

These keep the same architecture, but improve resilience:

Timeouts & retries for A2A calls (network I/O).
Avoid asyncio.run() if you ever run inside an existing event loop.
Return structured tool outputs (citations, metadata) if you need auditability later.

Why this architecture scales

Adding a new domain agent (Finance / Legal / Security) is just repetition of the same pattern:

1) new RAG agent handler with retrieve + domain prompt + KNOWLEDGE_BASE_ID

2) new orchestrator tool ask_finance_agent calling A2A

3) add tool to orchestrator’s tools=[...]

No refactor required.

Final thoughts

If you already know how to build RAG (or deterministic tools), the next step is orchestration.

This pattern gives you:

domain isolation
deployable units (AgentCore Runtime)
model-driven routing (tools)
a clean evolution path

It’s basically microservices:

small, focused services with a clear interface — except the services can reason.

RAG Works — Until You Hit the Long Tail

Meidi Airouche — Sun, 11 Jan 2026 23:23:12 +0000

Why Training Knowledge Into Weights Is the Next Step Beyond RAG

If you use ChatGPT or similar large language models on a daily basis, you have probably developed a certain level of trust in them. They are articulate, fast, and often impressively capable. Many engineers already rely on them for coding assistance, documentation, or architectural brainstorming.

And yet, sooner or later, you hit a wall.

You ask a question that actually matters in your day-to-day work — something internal, recent, or highly specific — and the model suddenly becomes vague, incorrect, or confidently wrong. This is not a prompting issue. It is a structural limitation.

This article explores why that happens, why current solutions only partially address the problem, and why training knowledge directly into model weights is likely to be a key part of the future.

The real problem is not the knowledge cutoff

The knowledge cutoff is the most visible limitation of LLMs. Models are trained on data up to a certain point in time, and anything that happens afterward simply does not exist for them.

In practice, however, this is rarely the most painful issue. Web search, APIs, and tools can often mitigate it.

The deeper problem is the long tail of knowledge.

In real production environments, the most valuable questions are rarely about well-documented public facts. They are about internal systems, undocumented decisions, proprietary processes, and domain-specific conventions that exist nowhere on the public internet.

Examples include:

Why did this service start failing after a seemingly unrelated change?
Has this architectural trade-off already been discussed internally?
How does our company interpret a specific regulatory constraint?

These questions live in the long tail. And that is exactly where large foundation models perform the worst.

Three ways to give knowledge to a language model

If we strip away tooling details, there are only three fundamental ways to make a language model “know” something new.

The first is to place the knowledge directly into the prompt.

The second is to retrieve relevant information at inference time.

The third is to train the knowledge into the model itself.

Most systems today rely almost entirely on the first two.

Full context: simple, expensive, and fragile

The most naive solution is to put everything into the prompt.

prompt = f"""
You are an assistant with access to our internal documentation.

{internal_docs}

Question:
Why does service X fail under load?
"""

For small documents, this works. It is easy to implement and requires no additional infrastructure.

However, as context grows, several issues appear at once. Token costs increase linearly. Latency increases significantly. Most importantly, reasoning quality degrades as more weakly relevant information is added.

This is not an implementation issue. It is a consequence of how transformer models work.

The transformer bottleneck and context degradation

Transformers rely on self-attention, where every token attends to every other token. This leads to quadratic complexity with respect to input length.

Even though modern models can technically accept very large context windows, there is an important difference between:

not crashing with long input, and
reasoning well over long input.

Empirically, performance degrades as context grows, even when the relevant information remains the same. The model continues to produce fluent text, but its ability to connect the right pieces of information deteriorates. This phenomenon is often referred to as context rot.

As a result, simply increasing the context window is not a viable long-term solution.

RAG: external memory via embeddings

To avoid pushing everything into the prompt, the industry converged on Retrieval-Augmented Generation (RAG).

The idea is to store documents externally, retrieve the most relevant ones using embeddings, and inject only those into the prompt.

A minimal Python example looks like this:

from langchain.vectorstores import Chroma
from langchain.embeddings import OpenAIEmbeddings

embeddings = OpenAIEmbeddings()
vector_store = Chroma.from_documents(
    documents=docs,
    embedding=embeddings
)

results = vector_store.similarity_search(
    query="Why does the CI pipeline fail?",
    k=5
)

RAG is popular because it is flexible, relatively cheap, and easy to deploy. Today, it is the default solution for adding memory to LLM-based systems.

Why RAG is fundamentally limited

RAG retrieves information, but retrieval is not reasoning. Selecting a few relevant chunks does not guarantee that the model can correctly combine them, especially when the answer depends on implicit relationships or multi-step reasoning across documents.

Embeddings also encode a single global notion of similarity. They are not adaptive to local domain semantics. In practice, documents that should never be confused often end up close together in vector space.

Finally, embeddings are not inherently secure. With enough effort, large portions of the original text can be reconstructed from them. This makes vector databases unsuitable as a privacy-preserving abstraction.

These limitations suggest that RAG is powerful, but incomplete.

The naive fine-tuning trap

At this point, it is tempting to fine-tune the model directly on internal data.

In practice, naive fine-tuning almost always fails. Training directly on small, specialized datasets causes the model to overfit, lose general reasoning abilities, and forget previously learned knowledge. This phenomenon is known as catastrophic forgetting.

The result is a model that memorizes patterns but loses its ability to generalize and reason beyond the training data.

Synthetic data as the missing link

The key insight that changes the picture is synthetic data generation.

Instead of training on raw documents, we generate a large and diverse set of tasks that describe the knowledge contained in those documents. These can include question–answer pairs, explanations, paraphrases, and counterfactuals.

A simplified example in Python:

def generate_qa(doc):
    return {
        "instruction": f"Explain the key idea behind: {doc.title}",
        "response": doc.summary
    }

synthetic_dataset = [generate_qa(doc) for doc in internal_docs]

This approach teaches the domain, not the surface text. Surprisingly, it works even when the original dataset is small, as long as the synthetic data is sufficiently diverse.

Training into weights without destroying the model

To avoid catastrophic forgetting, modern systems rely on parameter-efficient fine-tuning. Instead of updating all weights, only a small subset is modified.

One common technique is LoRA (Low-Rank Adaptation):

from peft import LoraConfig

lora_config = LoraConfig(
    r=8,
    lora_alpha=16,
    target_modules=["q_proj", "v_proj"]
)

The key idea is to make small, localized changes that steer the model without overwriting its existing knowledge.

Other approaches, such as prefix tuning or memory layers, follow the same principle with different trade-offs.

A hybrid future: context, retrieval, and weights

None of these techniques replaces the others entirely. The most effective systems combine all three.

Context is useful for immediate instructions. Retrieval is essential for fresh or frequently changing data. Training into weights provides deep, coherent domain understanding that retrieval alone cannot achieve.

The central design question going forward is not whether to train models on private knowledge, but what knowledge deserves to live in weights versus being handled at inference time.

Conclusion

RAG is a pragmatic and powerful solution, and it will remain part of the LLM ecosystem. However, it is fundamentally limited when it comes to deep reasoning over specialized knowledge.

As training techniques become more efficient, training knowledge into weights will no longer be a research curiosity. It will be an engineering decision.

In the long run, the most valuable LLM systems will not be defined by the base model they use, but by what they have been taught — and how carefully that teaching was done.

Guide d'apprentissage pour maîtriser GitHub Copilot

Patrice Eon — Tue, 23 Dec 2025 11:37:36 +0000

GitHub Copilot est le nouvel allié des développeurs pour coder plus vite et plus intelligemment.

Mais soyons honnêtes : la plupart d'entre nous l'utilisent comme une simple autocomplétion augmentée.

Résultat ? On exploite à peine 20 % de sa véritable puissance. C'est un peu comme avoir une Ferrari et ne jamais dépasser la deuxième vitesse.

En effet en 2025, GitHub Copilot a pris du muscle. Fini l'assistant timide qui suggère trois lignes de code. Place à un partenaire IA complet, dopé aux modèles de pointe (Claude Sonnet 4.5, GPT-5, Gemini 3 Pro). Il comprend désormais votre code dans son ensemble, orchestre des tâches complexes en autonomie et s'intègre parfaitement à votre écosystème de développement.

Ce guide existe pour une raison simple : vous faire passer de 20 % à 100 % d'utilisation. Grâce à 10 techniques éprouvées et des protocoles avancés, vous découvrirez comment transformer Copilot d'un simple assistant en copilote stratégique.

Parce qu'au final, l'objectif n'est pas juste de coder plus vite. C'est de coder plus intelligemment, en laissant l'IA gérer la vitesse pendant que vous vous concentrez sur ce qui compte vraiment : l'intelligence de vos solutions.

Table des matières

Partie I : Installation et présentation des fondamentaux (démarrage en douceur)
- 1.1 GitHub Copilot dans votre IDE vs GitHub Copilot CLI
- 1.2 Installer GitHub Copilot sur VS Code
- 1.3 Installer GitHub Copilot sur IntelliJ IDEA
- 1.4 Obtenir un compte GitHub avec accès Copilot
- 1.5 Installer GitHub Copilot CLI
- 1.6 GitHub Copilot dans votre IDE : Aperçu des contrôles et fonctionnalités
Partie II : Maîtriser les leviers de productivité
- 2.1 Maîtriser les Commandes Slash
- 2.2 Utiliser les Variables de Contexte
- 2.3 Créer des Instructions Personnalisées
- 2.4 Stratégie d'ouverture de Fichiers
- 2.5 Commenter le flux de travail
- 2.6 Le Dialogue itératif
- 2.7 Fichiers de prompts personnalisés
- 2.8 Glisser-Déposer de Contexte
- 2.9 Stratégie de Nettoyage de Contexte
- 2.10 Maîtriser la Sélection de Code
- 2.11 Créer des issues à partir de captures d’écran
- 2.12 Utiliser Github Copilot partout… Mais tirer le meilleur du plugin dans VS Code
Partie III : Écosystème et Agenticité Avancée
- 3.1 Le Protocole de Contexte Modèle (MCP)
- 3.2 Qu’est‑ce que « Awesome GitHub Copilot » ?
- 3.3 Custom agents
- 3.4 Maîtriser le GitHub Copilot CLI
Partie IV : Qualité, sécurité et rôle humain (Les Pièges)
- 4.1 Prendre les suggestions de Copilot pour des vérités
- 4.2 Ignorer la sécurité du code
- 4.3 Utiliser Copilot comme béquille pour les fondamentaux
- 4.4 Surcompliquer des solutions simples
- 4.5 Ne pas fournir de contexte pour de meilleures suggestions
- 4.6 Ne pas garder Copilot dans le bon scope
- 4.7 Zapper les tests parce que « Copilot l’a écrit »
Conclusion : Codez plus Intelligemment, pas seulement plus vite

Partie I : Installation et présentation des fondamentaux (démarrage en douceur)

Cette partie couvre l'installation, les accès, et la compréhension des modes d'interaction avec Github Copilot.

1.1 GitHub Copilot dans votre IDE vs GitHub Copilot CLI 🖊️

GitHub Copilot se déploie sur deux fronts stratégiques : directement intégré à votre IDE préféré (VS Code, IntelliJ...) pour une assistance en temps réel, et en ligne de commande pour orchestrer vos workflows depuis le terminal.

GitHub Copilot dans votre IDE

Fonctionnalités :

Complétion de code en temps réel (ligne ou fonction complète)
Copilot Chat intégré pour poser des questions ou générer des snippets
Intégration IDE : coloration, prévisualisation, acceptation avec Tab
Support multi-langages : Python, Java, JS, C++, Go, etc.

Usage typique :

Saisie de code et suggestions automatiques
Idéal pour une assistance immédiate et interactive dans l’éditeur

GitHub Copilot CLI

Fonctionnalités :

Assistant IA dans le terminal, indépendant de l’éditeur
Exploration de projet (fichiers, dépendances, structure)
Génération et modification de code via prompts en langage naturel
Exécution de commandes shell suggérées (avec confirmation)
Refactoring et workflows multi-étapes automatisés

Usage typique :

Travailler depuis le terminal, générer ou corriger du code
Idéal pour workflows scriptables ou projets distants

Comparaison rapide

Fonctionnalité	Copilot VS Code	Copilot CLI
Suggestions inline de code	✅ Oui	❌ Non
Chat intégré	✅ Oui	❌ Terminal-style
Modification de fichiers	✅ Oui	✅ Oui
Exécution commandes shell	❌	✅ Oui
Analyse globale du projet	Limité	✅ Oui
Indépendant de l’éditeur	❌	✅ Oui
Automatisation & workflows complexes	Moyen	✅ Oui

Résumé : VS Code pour coder efficacement au quotidien, CLI pour gérer et transformer des projets depuis le terminal.

1.2 Installer GitHub Copilot sur VS Code 🧩

La documentation officielle pour installer GitHub Copilot dans VS Code se trouve ici : Copilot VS Code extension

Ouvrir VS Code
Aller dans la Marketplace des extensions (Ctrl+Shift+X ou Cmd+Shift+X sur Mac)
Rechercher GitHub Copilot
Cliquer sur Installer
Se connecter à GitHub quand demandé (OAuth)
Les suggestions apparaissent automatiquement
Pour activer/désactiver : Ctrl+Shift+P / Cmd+Shift+P → taper Copilot → Enable/Disable GitHub Copilot

Astuce :

Configurer les suggestions dans Fichier → Préférences → Paramètres → GitHub Copilot

Fonctionne avec Python, Java, JS, C++, Go, etc.

1.3 Installer GitHub Copilot sur IntelliJ IDEA 🧩

La documentation officielle pour installer GitHub Copilot dans IntelliJ (mais également les autres IDE supporté) se trouve ici : Copilot Jetbrains extension

Ouvrir IntelliJ IDEA
Aller dans File → Settings → Plugins (Preferences → Plugins sur Mac)
Cliquer sur Marketplace, chercher GitHub Copilot
Cliquer sur Installer
Redémarrer IntelliJ
Se connecter à GitHub pour activer Copilot
Les suggestions apparaissent automatiquement lors de la saisie de code

Astuce :

Activer/désactiver : Settings → GitHub Copilot
Utilisable aussi dans le terminal intégré pour générer des snippets

1.4 Obtenir un compte GitHub avec accès Copilot 📝

Étape 1 : Créer un compte GitHub

Aller sur https://github.com/join
Remplir le formulaire (nom d’utilisateur, email, mot de passe)
Confirmer votre email

Étape 2 : Activer GitHub Copilot

Option	Type d’abonnement	Coût	Étapes
A	Free	0$	1. Aller sur https://github.com/features/copilot 2. Cliquer sur Free 3. Suivre l’activation
B	Pro	~10$/mois ou 100$/an	Aller sur https://github.com/settings/billing → entrer les informations de paiement
C	Pro+	~39$/mois ou 390$/an	Aller sur https://github.com/settings/billing → entrer les informations de paiement

Alternative : Abonnement Etudiant (gratuit)

Aller sur GitHub Student Developer Pack

Étape 3 : Vérifier l’accès

Aller sur https://github.com/features/copilot
Vérifier le message “You have access” ou la période d’essai en cours
Installer l’extension dans VS Code ou IntelliJ et commencer à coder

1.5 Installer GitHub Copilot CLI 🚀

GitHub Copilot CLI, permet de déléguer une tâche à l'IA directement dans votre terminal — exit l'éditeur de code.

Pourquoi l'installer maintenant ? Parce que l'usage agentique avancé (détaillé plus loin dans ce guide) repose sur cette base.

Prérequis

Un compte GitHub avec accès à Copilot activé (voir section précédente)
Node.js version 20 ou supérieure installé

Étapes d'installation

Ouvrir votre terminal
Installer l'extension GitHub CLI si ce n'est pas déjà fait :

# Sur macOS/Linux avec Homebrew
brew install gh

# Sur Windows avec winget
winget install --id GitHub.cli

Se connecter à GitHub :

gh auth login

Installer l'extension Copilot CLI :

gh extension install github/gh-copilot

Vérifier l'installation :

gh copilot --version

Utilisation basique

Une fois installé, vous pouvez utiliser Copilot directement dans le terminal :

# Demander de l'aide sur une commande
gh copilot suggest "comment lister tous les fichiers modifiés dans les 7 derniers jours"

# Expliquer une commande complexe
gh copilot explain "git rebase -i HEAD~3"

Astuce :

La documentation complète est disponible sur : GitHub Copilot CLI Documentation
Utilisez gh copilot --help pour voir toutes les commandes disponibles

1.6 GitHub Copilot dans votre IDE : Aperçu des contrôles et fonctionnalités 🎛️

N’utiliser qu’un prompt basique (comme ci‑dessous) sans exploiter les autres fonctionnalités utiles de GitHub Copilot peut sembler assez limitant.

C’est pourquoi je partage une collection d’astuces pratiques; vous en reconnaîtrez certaines, mais j’espère que quelques‑unes vous inspireront à tirer pleinement parti de ce que Copilot peut offrir.

1.6.1 Les contrôles du panneau de chat

Configurer un nouveau contexte pour vos prompts. Utile pour repartir à zéro sur des tâches non liées.
Réouvrir les contextes de prompts historiques utilisés auparavant. Utile pour basculer entre différents contextes.
Générer des fichiers de prompt, des instructions, etc. (voir la section Meta Prompting ci‑dessous)
Options supplémentaires de configuration de la fenêtre de chat (prompt)
Maximiser votre fenêtre de chat (prompt)
Masquer votre fenêtre de chat (prompt)

1.6.2 Modes Agent, Ask, Edit, Plan et Configure

Choisissez comment vous voulez que GitHub Copilot vous aide. Dans beaucoup de cas, vous utiliserez simplement l’Agent. Difficile de voir pourquoi on aurait encore besoin de Ask ou Edit une fois qu’on a l’Agent, utilisé pour notre Vibe Programming !

En réalité, ces trois modes répondent à des intentions différentes :

Ask est le mode conversation et compréhension. Il sert à poser des questions, demander des explications, explorer une API, comprendre un bout de code ou valider une approche sans modifier votre code. C’est idéal pour réfléchir, apprendre ou lever un doute rapidement.
Edit est le mode chirurgical. Vous sélectionnez du code et demandez une transformation précise : refactoriser, renommer, optimiser, traduire un commentaire, corriger un bug local. Copilot agit uniquement sur la zone ciblée, sans initiative au-delà de ce que vous avez demandé. Parfait quand vous voulez garder un contrôle strict.
Agent est le mode autonome et orienté objectif. Vous lui donnez une intention globale (« ajoute l’authentification », « implémente cette feature », « corrige les tests cassés ») et il explore le projet, crée ou modifie plusieurs fichiers, exécute des actions et itère. C’est le compagnon idéal pour le Vibe Programming, quand vous voulez avancer vite et laisser Copilot prendre des décisions.

👉 En résumé :

Ask = comprendre et discuter
Edit = modifier précisément
Agent = déléguer et construire

Les trois sont complémentaires : Agent pour aller vite, Edit pour ajuster, Ask pour comprendre.

Passer par Configure custum Agents est utile pour fournir de meilleures instructions à l’agent afin de permettre des prompts plus puissants. Vous pouvez en savoir plus loin dans l’article.

1.6.3 Sélection des modèles LLM

Sélectionnez le modèle LLM que vous souhaitez utiliser. Certains modèles sont meilleurs que d’autres. D’après mon expérience, Claude Sonnet est plus pertinent que GPT.

Mais attention, l’utilisation des modèles est limitée par le quota de requêtes indiqué par 0x, 1x et 3x. Ce sont des multiplicateurs appliqués à votre quota de requêtes premium.

0x : utilisation illimitée
1x : exactement votre quota de requêtes
3x : 3× votre quota de requêtes

Donc, utilisez‑les avec parcimonie selon vos besoins.

Le mode Agent de GitHub Copilot est devenu l’un des meilleurs agents de code depuis quelques mois.
Il peut analyser votre projet entier, traiter des issues GitHub, rédiger des pull requests, et même aider à écrire des tests.

Quel modèle fonctionne réellement le mieux en mode Agent de Copilot ?

Gemini 3 Pro : Le débogueur UI

Gemini 3 Pro de Google apportent quelque chose d’unique : un véritable raisonnement multimodal.

Cela signifie qu’il peut comprendre code, texte, images et même diagrammes en une seule passe.

Idéal pour :

Débogage UI ou visuel
Analyse code + documents
Pipelines de données en entreprise

Avantages :

✅ Excellent pour le raisonnement visuel
✅ Rapide, économique et scalable
✅ Excelle dans le traitement parallèle et l’orchestration d’outils

Inconvénients :

❌ Donne parfois des solutions génériques pour des tâches générales.
❌ Moins « réfléchi » que Claude pour le raisonnement profond.

GPT-5 : Le penseur profond

Si votre travail implique du raisonnement multi-étapes, du débogage complexe ou une analyse au niveau de l’architecture, GPT-5 brille — mais il faut bien l’instruire avec des prompts. Ses capacités d’analyse surpassent de nombreux autres modèles, et il peut résoudre des bugs complexes tout en offrant une vue d’ensemble plus claire du scénario.

Idéal pour :

Gros refactorings multi-fichiers
Raisonnement et débogage profonds
Projets nécessitant une compréhension contextuelle longue

Avantages :

✅ Très fort en raisonnement logique
✅ Gère texte + vision (excellent pour les diffs UI et captures d’écran [pas encore testé])
✅ Modes de raisonnement contrôlables

Inconvénients :

❌ Plus lent que les modèles légers.
❌ Moins économique pour les petits projets

Vous vous sentez bloqué ? Revenez au point de départ et expliquez tout le cas d’usage. Boom — c’est probablement le meilleur modèle pour résoudre ces casse-têtes. Un peu lent, mais efficace.

Claude Sonnet 4.5 : Le polyvalent raffiné

S’il y a un modèle qui se rapproche le plus d’un ingénieur senior, c’est Claude Sonnet 4.5.

Développé par Anthropic, Claude est reconnu pour sa clarté, sa fiabilité et sa capacité à gérer des immenses bases de code — jusqu’à 1 million de tokens.

Idéal pour :

Dépôts de niveau entreprise
Tâches autonomes de plusieurs heures
Sorties sûres et à faible hallucination

Avantages :

✅ Gère d’énormes fenêtres de contexte
✅ Excellent pour les grands monorepos et les refactorings
✅ Faible taux d’hallucination et ton cohérent

Inconvénients :

❌ Limité par le débit sur les configurations gratuites ou partagées
❌ Tarification légèrement premium

Avis personnel :

Claude Sonnet génère généralement un code plus propre et plus fiable que les autres. Mais quand vous atteignez les limites de débit, c’est frustrant — surtout lors de longues sessions.

Astuce : Pour des agents longue durée (comme des migrations de données ou des audits de dépôt), Claude Sonnet 4.5 est le choix le plus sûr.

1.6.4 Tableau de bord d’utilisation de Copilot

Vous pouvez voir combien vous avez utilisé de requêtes premium ce mois‑ci. Avec un abonnement PRO payant, vous avez un quota mensuel de 300 requêtes.

Notez que l’allocation est réinitialisée le premier du mois prochain.

1.6.5 Contrôle de l’activité des prompts

C’est ici que vous lancez le prompt ou l’arrêtez (s’il tourne)
Après la réponse, vous pouvez garder les changements effectués par l’agent ou les annuler.
Pour certaines étapes, il demandera votre permission avant d’agir (ex. exécuter une appli, installer, supprimer un fichier, etc.). Vous pouvez aussi le configurer pour toujours autoriser.

1.6.6 Fichier de contexte pour l’agent

Vous pouvez limiter votre agent à un contexte spécifique, qui peut être :

Un fichier ouvert
Une partie du fichier ouvert (comme sur le schéma ci‑dessus, de la ligne 11 à 16)
Ou joindre un nouveau fichier (ex. une image que l’agent lira, puis codera)
Utiliser # pour indiquer un fichier d’intérêt, @ pour accéder à l’extension et / pour accéder à une commande ou un fichier de prompt.

1.6.7 Gestion de code (Source Control)

Vous pouvez effectuer la gestion de code directement depuis VS Code.

Accéder à Source Control. S’il n’y en a pas, un bouton permet de l’initialiser ici
Ajouter (au contrôle de source), retirer ou ouvrir les fichiers modifiés
Écrire votre message de commit ici, ou utiliser l’IA (bouton étoile) pour le générer
Valider vos changements ajoutés, et choisir Amend, Push ou Sync avec le commit.

1.6.8 Paramètres de l’extension GitHub Copilot

Ouvrir le panneau des Extensions
Sélectionner les paramètres de Copilot
Vous pouvez maintenant activer l’autocomplétion pour le Markdown ou le texte brut !!

Partie II : Maîtriser les leviers de productivité

Cette section est le cœur du guide, détaillant les stratégies pratiques pour améliorer la précision et l'efficacité.

2.1 Maîtriser les commandes Slash

Les slash commandes sont des raccourcis intégrés qui évitent des prompts interminables. Tapez / dans Copilot Chat pour débloquer une productivité instantanée.

Slash Commands essentielles :

/tests — Génère des tests unitaires complets pour le code sélectionné, avec cas limites et mocks
/fix — Analyse les erreurs et propose des correctifs (null checks, refactors)
/explain — Explique des snippets de code complexes
/doc — Génère des commentaires de documentation pour fonctions et classes
/refactor — Suggère des améliorations et optimisations de code

Astuce : Combinez /tests avec #file:src/service.ts pour générer des tests spécifiques au service sans boilerplate.

Pourquoi c’est important : Ces commandes fonctionnent en chat et en inline (Alt+/) et sont incluses dans l’offre basique. Commencez par /tests et /fix — des gains rapides pour tout codebase.

Impact réel : Sur ce projet e‑commerce, /tests m’a à lui seul économisé 8 à 10 heures d’écriture de tests manuels sur tous les services.

Note gratuit vs payant : la version gratuite limite vos requêtes mensuelles. En gratuit, je me cognais les limites en plein projet. D’où mon passage à l’abonnement payant (10 $/mois individuel). Si vous utilisez Copilot au quotidien, le payant vaut le coup rien que pour l’illimité.

2.2 Utiliser les Variables de Contexte 📦

Copilot n’est pas devin. Plus vous lui donnez de contexte, mieux il vous aide.

Variables de contexte puissantes :

#file — Référencez des fichiers précis : #file:auth.service.ts
#codebase — Laissez Copilot fouiller toute votre base de code
#editor — Ajoute tous les fichiers ouverts au contexte
@workspace — Posez des questions sur toute la structure du projet
#fetch — Récupère du contenu web ou de la doc

Exemple en action :

@workspace Sur notre serveur Node, quelles optimisations pour gérer 10 000 requêtes concurrentes ?

Astuce : surlignez le code pertinent avant de questionner. Copilot donne alors des suggestions ciblées et évite les suppositions.

2.3 Créer des instructions personnalisées ✍️

Pour arrêtez de vous battre avec les suggestions : Définir les standards de codage de l'équipe (style, conventions, utilisation de const vs var) dans le fichier .instructions.md,. L'objectif est de garantir une cohérence permanente du code généré.

Configurer les instructions personnalisées :

Lancez Chat: New Instructions File depuis la palette de commandes
Cela crée .instructions.md dans le dossier .github/instructions
Définissez vos règles projet en Markdown

Exemple de fichier d’instructions :

Custom instructions for Copilot

Project Context
This project is a React + Node.js e-commerce platform

Code Style
- Use TypeScript strict mode
- Prefer functional components with hooks
- Use camelCase for variables
- Write descriptive variable names (no single letters)

Testing
- Use Jest for unit tests
- Use Playwright for E2E tests
- Always include error handling tests

Indentation
We use 2 spaces, not tabs

Pourquoi ça marche : Copilot génère désormais du code conforme à VOTRE style, pas des patterns génériques. Temps d’édition réduit jusqu’à 40 %.

2.4 Stratégie d'ouverture de fichiers 📂

Petit secret : Copilot ne voit pas les fichiers fermés. Ouvrir 3 à 5 fichiers liés lui donne un contexte massif sur la structure.

Stratégie d’ouverture maligne :

Avant d’écrire du nouveau code, ouvrez :

Le fichier que vous éditez
Les utilitaires/helpers liés
Les fichiers de types
Les fichiers de config
Des implémentations similaires existantes

Exemple : écrire un nouvel endpoint API ? Ouvrez :

routes/user.routes.ts (là où vous travaillez)
controllers/user.controller.ts (patterns existants)
models/User.ts (structure de données)
middleware/auth.ts (contexte d'authentification)

Rappel critique : fermez les fichiers hors sujet quand vous changez de tâche. Trop de fichiers non liés perturbent le contexte.

2.5 Commenter le Flux de travail 🗨️

Écrire des commentaires détaillés spécifiant l'architecture, le flux, le traitement des erreurs et les cas limites AVANT d'écrire le code. Cette planification augmente significativement la précision de la sortie de l'IA.

// Objectif : Auth JWT + refresh tokens + reset password sécurisé
// Flux : signup -> email verify -> login -> refresh -> logout
// Exigences : rate limiting, CSRF, rotation de refresh tokens, IP logging
// Cas limites : token expiré, utilisateur désactivé, tentative brute force

Voyez Copilot comme un dev junior. Plus vos consignes sont claires, meilleur est le résultat.

Workflow « comment-first »

Plutôt que plonger direct dans le code, écrivez en tête de fichier un commentaire descriptif expliquant l’architecture et le flux.

Résultat : Copilot génère un code qui suit vos spécifications, incluant la gestion d’erreurs et les cas limites.

Astuce : incluez des exemples d’entrées/sorties dans les commentaires. La précision des suggestions augmente fortement.

2.6 Le Dialogue itératif 🔄

Ne pas accepter la première suggestion. Affiner les résultats par des follow-up prompts spécifiques pour garantir la validation côté client ou l'ajout de logique manquante.

Gros morceau en 2025. Copilot CLI intègre Claude Sonnet 4.5 — et ce modèle est bluffant en code.

Fonctionnalités CLI puissantes :

/model — Changez de modèle IA à la volée
Exécution directe du shell avec le préfixe !
Support image via mentions @
Permissions d’outils améliorées avec des glob patterns

Exemple concret :

# Générer des commandes terminal complexes
gh copilot explain "How do I find all .js files modified in the last 7 days and run eslint on them?"

# Exécuter directement !
npm run test:unit

Astuce : utilisez la commande /usage pour suivre les requêtes premium et optimiser votre flux.

2.7 Fichiers de prompts personnalisés 🗃️

Créer des modèles réutilisables pour des requêtes complexes dans votre projet (.github/prompts/).

Le mode Agent permet à Copilot de travailler de façon autonome — trouver des fichiers, éditer du code, et décider sans saisie constante.

Quand utiliser le mode Agent :

Refactorings sur de grandes bases de code
Conversion entre frameworks
Implémentation de fonctionnalités à travers plusieurs fichiers
Débogage d’issues complexes

Comment activer :

Ctrl+Shift+Alt+L (Windows) ou Cmd+Shift+Alt+L (Mac)
Ou /agent dans le chat

Exemple de prompt :

Commande GitHub Copilot dans mon espace réel

@workspace Objectif :
Créer une page web statique qui présente une estimation des résultats du FC Nantes (FCN) pour la fin de saison de Ligue 1.

Contraintes générales :
Page web en HTML, CSS et JavaScript vanilla
Design moderne, lisible et responsive

Couleurs officielles du FC Nantes :
Jaune : #FFD700
Vert : #006A3D

Typographie sportive et élégante
Aucun framework externe

Note de sécurité : le mode Agent requiert votre validation avant exécution des changements. Relisez tout attentivement.

2.8 Glisser-Déposer de Contexte 🖱️

Contexte Visuel et Logistique : déposer des fichiers, des logs d'erreurs, des dossiers, et même des captures d'écran directement dans Copilot Chat pour une analyse immédiate. Utiliser le fichier package.json pour informer l'IA des dépendances.

Par ailleurs vous connaissez ce moment où vous êtes « dans la zone » et ne voulez pas changer de fenêtre ? L’inline chat est fait pour ça.

Raccourcis inline chat (je cherchais où l’ouvrir dans VS Code jusqu’à trouver ces raccourcis) :

Ctrl+I / Cmd+I — Démarrer le chat inline directement dans l’éditeur
Alt+/ — Accès rapide aux slash commands en inline

Cas parfaits :

Petites corrections en debug
Générer une fonction unique
Ajouter de la gestion d’erreurs à du code existant
Refactoriser un bloc précis

Workflow pro : surlignez le code problématique → Ctrl+I → tapez /fix → acceptez la suggestion → continuez à coder.

2.9 Stratégie de nettoyage de contexte 🧹

Supprimer les questions non pertinentes ou démarrer un nouveau fil de conversation pour éviter que l'historique ne dilue la qualité de la réponse (améliore la qualité de 30 %).

Sauvez vos meilleurs prompts et partagez‑les avec l’équipe. Les fichiers de prompt sont des templates réutilisables pour les tâches courantes.

Créer des fichiers de prompt :

Chat: New Prompt File via la palette
Enregistrez dans .github/prompts/
Écrivez le prompt en Markdown avec métadonnées

Exemple de fichier (.prompt.md) :

mode: 'agent'
tools: ['githubRepo', 'search/codebase']
description: 'Generate a new React component'
Your goal is to generate a new React component based on templates in #githubRepo yourcompany/design-system.
Requirements:
* Use TypeScript with strict types
* Follow design system patterns
* Include PropTypes
* Add Storybook story
* Include unit tests with React Testing Library

Utilisation : tapez /your-prompt-name dans le chat.

Bénéfice équipe : tout le monde suit les mêmes bonnes pratiques. Fini les styles incohérents.

2.10 Maîtriser la sélection de Code 🔍

Utiliser @selection ou mettre en surbrillance un bloc de code précis avant de poser une question afin d'obtenir des suggestions plus rapides et plus pertinentes.

Par ailleurs la fonction la plus simple mais sous‑utilisée : glissez des fichiers directement dans Copilot Chat.

Ce que vous pouvez glisser :

Plusieurs fichiers à la fois
Des dossiers entiers
Des captures et images (NOUVEAU en 2025 !)
Des logs d’erreurs du terminal
Des sorties d’échecs de tests

Cas puissant — rapport de bug :

Prenez une capture du bug UI
Glissez la capture dans Copilot Chat
Tapez : « Crée un rapport de bug pour ce problème de rendu »
Copilot analyse l’image et génère une documentation de bug détaillée

Astuce avancée : glissez votre package.json pour aider Copilot à comprendre vos dépendances et proposer du code compatible.

BONUS : stratégie « supprimer et redémarrer »

Copilot utilise l’historique de conversation comme contexte. S’il donne des réponses hors sujet :

Supprimez les anciennes questions non pertinentes
Démarrez un nouveau thread via le bouton +
Utilisez les flèches haut/bas pour naviguer dans l’historique (comme dans le terminal)

Cela garde la conversation ciblée et améliore la qualité des réponses d’environ 30 %.

Check‑list de gains rapides pour cette semaine

Avant de fermer cet article, engagez‑vous à tester ces trois points :

Ajoutez un fichier .instructions.md dans le répertoire instructions à la racine de votre projet principal, avec votre style de code
Installez Copilot CLI et essayez la commande /model avec Claude Sonnet 4.5
Ouvrez 4 à 5 fichiers liés la prochaine fois que vous écrivez du nouveau code et regardez les suggestions s’améliorer

2.11 Créer des issues à partir de captures d’écran 📸

Vous avez un rapport de bug avec une capture d’écran ? Ne l’écrivez pas manuellement, laissez Copilot s’en charger. Voici comment :

Prenez une capture d’écran du bug (par ex., une icône mal alignée ou un problème de mise en page)
Glissez-la dans la discussion Copilot sur github.com/copilot.
Ajoutez une consigne comme :

Crée un nouveau ticket en utilisant le label 'bug'. Utilise cette capture et décris l’icône de flèche qui se chevauche. Applique le modèle de ticket UI de ce dépôt.

Copilot lit l’image, génère un titre et une description clairs, applique les bons labels et utilise les modèles de tickets de votre dépôt. C’est plus rapide qu’une transcription manuelle et il repère souvent des détails que je pourrais manquer.

Astuce : Copilot peut déduire le contexte du ticket à partir de votre capture et de votre consigne ; pas besoin de tout expliciter.

2.12 Utiliser Github Copilot partout… Mais tirer le meilleur du plugin dans VS Code 🌐

Vous pouvez profiter de Github Copilot dans de nombreux IDE tels que Visual Studio Code, JetBrains, Visual Studio, Eclipse, XCode, Vim ou même Neovim.

L’idée est de garder votre environnement familier tout en bénéficiant des fonctionnalités de Github Copilot.

Néanmoins, les plugins VS Code pour Github Copilot sont souvent plus avancés et mis à jour plus fréquemment que pour les autres IDE.

Astuce : installez les plugins VS Code compatibles avec votre IDE préféré, et installez également VS Code en parallèle. Vous profitez ainsi du confort de votre environnement habituel tout en accédant facilement aux dernières nouveautés disponibles dans VS Code.

Partie III : Écosystème et Agenticité Avancée

Cette partie explore l'interopérabilité et les outils de niveau professionnel qui étendent Copilot au-delà de l'IDE.

3.1 Le Protocole de contexte Modèle (MCP) 🚀

Le MCP (Model Context Protocol) est un protocole d'interopérabilité — un peu comme un « USB-C pour les intégrations d'IA » — conçu pour étendre les capacités des modèles d’IA et leur permettre de se connecter de manière sécurisée et structurée à des outils, données et services externes.

Concrètement avec un MCP : L’IA peut accéder à des données réelles, appeler vos APIs, lire vos fichiers ou agir sur vos outils, selon des règles explicites.

Il existe plus de 30 intégrations MCP officielles, couvrant des domaines comme :

GitHub MCP propose un hub central pour la découverte et l'installation de serveurs MCP de partenaires (Figma, Postman, Terraform) Github hub central mcp server.

Intégration/Produit	Type	Résumé	Cas d'usage rapides
Conversion fichiers → Markdown	Utilitaire/Conversion	Convertir PDF, Word, Excel, images, audio en Markdown.	Markdown depuis PDF/Doc
GitHub (assistants IA)	DevOps	Gérer dépôts, issues, PR, workflows en langage naturel.	Gérer issues/PR
Chrome DevTools	DevTools	Serveur MCP pour Chrome DevTools.	Inspecter runtime
Notion (officiel)	Productivité	Serveur MCP officiel pour l’API Notion.	Notes/DB Notion
Azure MCP Tools	Cloud Integrations	Outils Azure MCP pour connecter agents IA et services Azure.	Azure services
Terraform (HCP/Enterprise)	IaC	Générer Terraform plus précis et automatiser workflows.	Infra as Code
Azure DevOps	DevOps	Dépôts, work items, builds, releases, tests, recherche de code.	Repos/CI/CD
Elasticsearch	Recherche/Analytics	Requêtes de recherche, mappings, ES	QL, shards via NL.
Hugging Face	IA/Modèles	Accéder modèles, datasets, Spaces, articles, collections.	Modèles/datasets
Jira + Confluence (remote)	Collaboration IT	Connexion sécurisée Jira/Confluence avec LLM/IDE/plateformes d’agents.	ITSM/Confluence

Expérimenter avec GitHub MCP

Je vous encourage à essayer GitHub MCP par vous-même. Voici comment configurer un serveur MCP localement :
setup github mcp server.

Une fois que GitHub MCP est lancé, vous pouvez le solliciter et l’utiliser.

Dans mon cas, je veux ajouter un nouvel élément de technologie à https://github.com/GoogleCloudPlatform/Template.

Le prompt que j’utilise est le suivant :

Use the GitHub MCP.
Refers to https://github.com/GoogleCloudPlatform/Template,
- Reads the contribution.md, and
- Create a technology item for Perplexity LLM Model, and
- Make a unique branch for the new Technology Item and
- Open a git issue and pull request

Il va alors utiliser Get File, Create Branch, Update File, Open Issue, Open Pull Request, et effectuer toutes les tâches nécessaires disponibles dans MCP Server : GitHub.

Personnellement, j’interagis beaucoup avec les MCP suivants :

Azure DevOps MCP : Voir les éléments de travail, mettre à jour le statut des tâches (ex. : passer à "Code Review"), gérer les PR sans quitter VS Code, réduisant la commutation de contexte.

Agent de Codage Teams : Déléguer des tâches à l'Agent via @GitHub dans Microsoft Teams, qui exécute la tâche sur le dépôt et crée automatiquement une Pull Request.

Chrome DevTools MCP : Utiliser l'Agent pour analyser la performance web (Largest Contentful Paint (LCP), Interaction to Next Paint (INP)) sur n'importe quelle URL.

3.2 🚀 Qu’est‑ce que « Awesome GitHub Copilot » ? 📡

Ce dépôt fournit une boîte à outils complète pour enrichir GitHub Copilot avec :

👉 Awesome Agents — Agents GitHub Copilot spécialisés qui s’intègrent aux serveurs MCP pour offrir des capacités étendues pour des workflows et outils spécifiques
👉 Awesome Prompts — Prompts ciblés et spécifiques à une tâche pour générer du code, de la documentation et résoudre des problèmes précis
👉 Awesome Instructions — Normes de codage et bonnes pratiques exhaustives applicables à des motifs de fichiers ou à des projets entiers
👉 Awesome Collections — Collections organisées de prompts, d’instructions et de modes de chat autour de thèmes et workflows spécifiques

🎯 Pourquoi utiliser « Awesome GitHub Copilot » ?

Productivité : des agents, prompts et instructions préconstruits font gagner du temps et assurent des résultats cohérents.
Bonnes pratiques : bénéficiez de normes et patterns de codage sélectionnés par la communauté.
Assistance spécialisée : accédez à des conseils de niveau expert via des agents personnalisés spécialisés.
Apprentissage continu : restez à jour sur les derniers patterns et pratiques à travers les technologies.

📖 Structure du dépôt

Structure du dépôt Awesome

├── prompts/          # Prompts spécifiques aux tâches (.prompt.md)
├── instructions/     # Normes de codage et bonnes pratiques (.instructions.md)
├── agents/           # Personas IA et modes spécialisés (.agent.md)
├── collections/      # Collections organisées d’éléments liés (.collection.yml)
└── scripts/          # Scripts utilitaires pour la maintenance

🎯 Comment utiliser les ressources « Awesome GitHub Copilot » ?

🤖 Agents personnalisés

Les agents personnalisés peuvent être utilisés dans Copilot Coding Agent (CCA), VS Code et Copilot CLI. Pour le CCA, lors de l’assignation d’un ticket à Copilot, sélectionnez l’agent personnalisé dans la liste fournie. Dans VS Code, vous pouvez activer l’agent personnalisé dans la session des agents, aux côtés des agents intégrés comme Plan et Agent.

🎯 Prompts

Utilisez la commande / dans GitHub Copilot Chat pour accéder aux prompts :

/awesome-copilot create-readme

📋 Instructions

Les instructions s’appliquent automatiquement aux fichiers selon leurs motifs et fournissent des conseils contextuels sur les normes de codage, les frameworks et les bonnes pratiques.

3.3 Custom agents 🤖

Un custom agent est un assistant IA personnalisé dans VS Code qui adopte une personnalité et un comportement spécifiques pour des tâches de développement précises. Par exemple, vous pouvez créer des agents pour :

Un planificateur de projet
Un réviseur de code sécurisé
Un architecte de solutions
Un testeur automatique

Chaque agent possède ses propres instructions, outils disponibles et comportements.

Pourquoi utiliser des Custom Agents ?

Spécialisation des tâches

Différentes tâches nécessitent différentes capacités. Un agent de planification peut n'avoir accès qu'à des outils de lecture pour éviter les modifications accidentelles, tandis qu'un agent d'implémentation aura tous les outils d'édition.

Instructions personnalisées

Chaque agent peut avoir des instructions spécifiques qui définissent comment l'IA doit fonctionner, garantissant des réponses cohérentes et adaptées à chaque fois.

Structure d'un fichier Custom Agent

Les custom agents sont définis dans des fichiers .agent.md (Markdown) avec cette structure :

En-tête (YAML frontmatter)

---
description: Générer un plan d'implémentation pour de nouvelles fonctionnalités
name: Planificateur
tools: ['fetch', 'githubRepo', 'search']
model: Claude Sonnet 4
handoffs:
  - label: Implémenter le plan
    agent: implementation
    prompt: Implémente le plan ci-dessus
    send: false
---

Champs disponibles :

description : Description brève de l'agent
name : Nom de l'agent
tools : Liste des outils disponibles
model : Modèle IA à utiliser
handoffs : Transitions suggérées vers d'autres agents

Corps du fichier

Le corps contient les instructions en Markdown qui guident le comportement de l'agent.

Créer un Custom Agent

Étape 1 : Créer le fichier

Ouvrez la liste des agents dans le Chat
Sélectionnez Configure Custom Agents
Cliquez sur Create new custom agent
Choisissez l'emplacement :
- Workspace : dans .github/agents (uniquement pour ce projet)
- User profile : pour tous vos projets

Étape 2 : Définir l'agent

Remplissez le fichier .agent.md :

---
description: Génère un plan d'implémentation détaillé
name: Plan
tools: ['search', 'fetch', 'githubRepo']
---

# Instructions de planification

Tu es en mode planification. Ta tâche est de générer un plan d'implémentation 
pour une nouvelle fonctionnalité.

Le plan doit inclure :
- Vue d'ensemble
- Exigences
- Étapes d'implémentation
- Tests nécessaires

Ne fais aucune modification de code, génère uniquement un plan.

Les Handoffs : enchaîner les agents

Les handoffs permettent de créer des workflows guidés entre agents avec des boutons de transition.

Exemple de workflow :

Planification → Implémentation : Générer un plan puis coder
Implémentation → Révision : Coder puis vérifier la qualité
Tests échouants → Tests réussis : Écrire les tests puis l'implémentation

handoffs:
  - label: Commencer l'implémentation
    agent: implementation
    prompt: Implémente maintenant le plan ci-dessus.
    send: false

label : Texte du bouton
agent : Agent cible
prompt : Texte à envoyer
send : Envoyer automatiquement (true/false)

Outils disponibles

Vous pouvez spécifier quels outils sont accessibles à chaque agent :

Outils VS Code intégrés : 'search', 'fetch', 'githubRepo'
Outils MCP : tous les outils d'un serveur avec 'nom-serveur/*'
Outils d'extensions

Exemple complet

---
description: Agent de révision de code se concentrant sur la sécurité
name: Réviseur Sécurité
tools: ['search', 'fetch']
model: Claude Sonnet 4
handoffs:
  - label: Corriger les problèmes
    agent: implementation
    prompt: Corrige les problèmes de sécurité identifiés ci-dessus.
---

# Instructions de révision sécurité

Tu es un expert en sécurité applicative. Analyse le code pour :

1. **Vulnérabilités de sécurité**
   - Injections SQL
   - XSS
   - CSRF
   - Fuites de données sensibles

2. **Bonnes pratiques**
   - Validation des entrées
   - Gestion des erreurs
   - Principe du moindre privilège

Pour chaque problème trouvé, fournis :
- Description claire
- Niveau de gravité
- Suggestion de correction

Partager les Custom Agents

Au niveau de l'équipe

Placez les fichiers dans .github/agents de votre workspace.

Au niveau de l'organisation

Les agents peuvent être définis au niveau GitHub Organization pour être disponibles dans tous les projets. Activez l'option dans les paramètres :

github.copilot.chat.customAgents.showOrganizationAndEnterpriseAgents

Conseils pratiques

Commencez simple : Créez d'abord des agents avec des rôles clairs
Limitez les outils : Donnez uniquement les outils nécessaires à chaque agent
Instructions précises : Plus les instructions sont claires, meilleurs sont les résultats
Utilisez les handoffs : Créez des workflows fluides entre agents
Testez et itérez : Affinez vos agents au fil de l'utilisation

3.4 Maîtriser le GitHub Copilot CLI 🚀

La GitHub Copilot CLI apporte les capacités IA de Copilot directement dans votre ligne de commande.

Plutôt que de jongler entre votre IDE et votre navigateur, vous pouvez faire appel à Copilot directement dans votre terminal pour les cas d'usage suivants :

Assistant IA dans le terminal, indépendant de l’éditeur
Exploration du projet (fichiers, dépendances, structure)
Génération et modification de code via des prompts en langage naturel
Exécution de commandes shell suggérées (avec confirmation)
Refactoring et automatisation de workflows multi-étapes

Vous pouvez utiliser Copilot CLI de deux manières :

Mode interactif (mode par défaut) : démarrez une session avec la commande copilot et conversez en aller‑retour, en affinant les tâches au fil de l’eau.
Mode programmatique : pour des prompts ponctuels. Passez une requête directement avec -p ou --prompt, et Copilot répond en ligne. Pour les tâches impliquant la modification ou l’exécution de fichiers, vous pouvez activer les options d’approbation pour garder les choses sûres et cohérentes.

Par exemple, vous pouvez demander :

copilot "create a bash script to check for uncommitted changes and push if clean"

ou bien en mode programmatique :

copilot -p "create a bash script to check for uncommitted changes and push if clean"

Copilot CLI écrira le script, expliquera ce qu’il fait, et vous demandera de confirmer avant de l’exécuter.

Copilot CLI demandera par défaut toujours une confirmation avant de lire, modifier ou exécuter des fichiers. Vous gardez ainsi donc le contrôle de votre environnement. (Note : Exception si vous choisissez « Yes, and remember this folder for future sessions » ou « Yes, and approve TOOL for the rest of the session » lorsque c’est demandé—Copilot suivra alors ces instructions au lieu de vous reposer la question. Plus de détails dans notre kit de démarrage ci‑dessous !)

Vous pouvez sélectionner l’une de ces options :

Yes, proceed : Copilot peut accéder et utiliser les fichiers de cet emplacement uniquement pour cette session.
Yes, and remember this folder for future sessions : les fichiers de ce dossier sont approuvés pour les sessions en cours et futures. En démarrant Copilot CLI depuis ce dossier, cette question ne vous sera plus posée (ne choisissez cette option que si vous êtes sûr qu’il sera toujours sans risque pour Copilot de travailler avec ces fichiers).
No, exit (Esc) : mettre fin à votre session Copilot CLI.

Cas d’usage de GitHub Copilot CLI, refactoring et automatisation de workflows multi-étapes avec un agent

L’option --allow-all-tools dans GitHub Copilot CLI permet d'autoriser Copilot à utiliser automatiquement tous les outils disponibles sur votre système, sans vous demander confirmation à chaque fois.

Exemple :

copilot --allow-all-tools -p "create a bash script to check for uncommitted changes and push if clean"

Partie IV : Qualité, sécurité et rôle humain (Les pièges à éviter)

Cette section est dédiée à la responsabilité du développeur et aux erreurs critiques à éviter ⚠️.

4.1 Prendre les suggestions de Copilot pour des vérités 🤖

L’erreur : Beaucoup de développeurs acceptent les suggestions de Copilot sans double vérification ✅❌.
Pourquoi c’est un problème : Le code généré par IA peut sembler correct mais contenir des bugs subtils 🐛, des problèmes de performance ⚡ ou des patterns obsolètes 📉.
Correctif : Traitez la sortie de Copilot comme des extraits Stack Overflow : relisez, testez et refactorisez avant de committer ✍️. Demandez-vous toujours : « Est-ce que j’écrirais ceci si Copilot ne me l’avait pas suggéré ? »

4.2 Ignorer la sécurité du code 🔒

L’erreur : Copilot peut générer du code non sécurisé (ex. requêtes SQL sans paramétrage, regex dangereuses, gestion faible des mots de passe).
Pourquoi c’est un problème : L’IA ne priorise pas intrinsèquement les bonnes pratiques de sécurité 🚨. Copier-coller aveuglément peut conduire à des vulnérabilités.
Correctif : Appliquez les pratiques de codage sécurisé : validez les entrées ✅, échappez les requêtes 🛡️, nettoyez les sorties ✨. Lancez une analyse statique (ex. SonarQube, plugins de sécurité ESLint) sur le code généré par Copilot.

4.3 Utiliser Copilot comme béquille pour les fondamentaux 🏗️

L’erreur : S’appuyer sur Copilot au lieu de comprendre le langage ou le framework sous-jacent 📚.
Pourquoi c’est un problème : Si vous ne savez pas pourquoi le code fonctionne, vous aurez du mal à le déboguer 🔍 ou l’étendre plus tard.
Correctif : Utilisez Copilot comme assistant d’apprentissage 🎓, pas comme substitut. Après avoir accepté une suggestion, faites une pause et expliquez-la (à vous-même ou en commentaire) avant de continuer.

4.4 Surcompliquer des solutions simples ✂️

L’erreur : Copilot génère parfois des solutions verbeuses pour des problèmes qui pourraient être résolus en une ligne 📝.
Pourquoi c’est un problème : La sur-ingénierie alourdit votre codebase ⚖️ et rend la maintenance plus difficile.
Correctif : Gardez le jugement du développeur dans la boucle 👨‍💻. Si la suggestion semble trop longue, demandez-vous s’il existe une solution plus élégante. Less is more.

4.5 Ne pas fournir de contexte pour de meilleures suggestions 🗂️

L’erreur : Écrire des noms de fonctions ou des commentaires vagues, puis s’attendre à ce que Copilot « sache » ce que vous voulez.
Pourquoi c’est un problème : L’IA se nourrit de contexte. Sans contexte, les suggestions peuvent être hors sujet ou déroutantes ❓.
Correctif : Rédigez des signatures de fonctions, commentaires et docstrings clairs ✏️. Exemple : au lieu de function processData(), utilisez function normalizeUserInput(userData: string[]): string[].

4.6 Ne pas garder Copilot dans le bon scope 🎯

L’erreur : Utiliser Copilot dans de grands fichiers encombrés sans contexte guide 🗃️.
Pourquoi c’est un problème : Copilot puise le contexte dans le code proche. Si votre fichier est chaotique, les suggestions deviennent moins précises ⚠️.
Correctif : Refactorez en modules plus petits et ciblés 🧩. Plus votre code est propre, plus Copilot devient pertinent.

4.7 Zapper les tests parce que « Copilot l’a écrit » 🧪

L’erreur : Supposer que la sortie de Copilot n’a pas besoin d’être testée en profondeur.
Pourquoi c’est un problème : Les suggestions de l’IA peuvent introduire des cas limites que vous n’aviez pas anticipés 🚫.
Correctif : Écrivez des tests unitaires, des tests d’intégration et des vérifications de cas limites pour tout code généré par Copilot. Bonus : Utilisez Copilot lui-même pour rédiger des cas de test — puis affinez-les manuellement 🛠️.

Conclusion : Codez plus intelligemment, pas seulement plus vite

GitHub Copilot n’est plus une autocomplétion ✨ : c’est un partenaire de développement capable d’orchestrer des tâches, d’analyser votre codebase et de s’intégrer à vos outils.

En combinant les fondamentaux (IDE vs CLI), les leviers de précision (slash commands, contexte, instructions, sélection) et l'agentique avancée (mode Agent 🤖, MCP 🧩, agents personnalisés 🛠️), vous passez de « coder plus vite » à « livrer mieux, avec maîtrise ».

La clé reste humaine 🧠 : cadrer le besoin, donner le bon contexte, et garder un œil critique sur la qualité, la sécurité et les tests.

En 2026, la différence viendra de ceux qui standardisent, automatisent et mesurent.

Plan d’actions immédiates

.instructions.md : formalisez vos normes d’équipe pour des sorties cohérentes.
/tests et /fix : sécurisez la qualité dès le flux quotidien.
Commentaire‑d’abord : décrivez architecture et cas limites avant de coder.
Contexte ciblé : ouvrez 3–5 fichiers pertinents, fermez le reste.
Copilot CLI : installez‑le et utilisez‑le pour scripts, issues et PR.
1 agent personnalisé : « Réviseur Sécurité » ou « Planificateur » + un handoff simple.

Cap sur 2026 : standardisez, automatisez, mesurez. Faites de Copilot votre accélérateur — et de vos pratiques, votre avantage.

Explorez plus de contenus sur GitHub et Copilot

Tout ce dont vous avez besoin pour maîtriser GitHub Copilot :

Documentation officielle

VS Code et Copilot

Ressources complémentaires

Quelle est la taille idéale d'une classe ?

Sébastien Bertrand — Tue, 23 Dec 2025 09:00:00 +0000

L'évaluation de la maintenabilité des programmes est un enjeu majeur pour l'industrie logicielle. En effet, selon Canfora et Cimitile (2001), la maintenance représente entre 60% et 80% du coût total d'un programme, en incluant les évolutions et les corrections d'anomalies. Toujours selon ces auteurs, le facteur le plus déterminant est la compréhension du programme déjà écrit.

De nos jours, l'approche classique d'évaluation de la maintenabilité repose sur l'apprentissage automatique. Cela consiste d'abord à compter un certain nombre d'éléments du code source qui nous intéressent, les fameuses métriques, puis à entrainer un algorithme pour prédire la maintenabilité à partir de ces métriques.

Afin d'entraîner convenablement les algorithmes, il est nécessaire d'avoir une valeur de référence fiable, comme le jeu de données de Schnappinger et al (2020) basé sur des évaluations par des experts. Pour des raisons pratiques, il est plus simple pour les experts d'évaluer la maintenabilité au niveau des classes. La figure ci-dessous présente ce jeu de données. Elle représente la maintenabilité en fonction de la taille des classes, exprimée ici en nombre de lignes (LOC - Lines of Code), unité universelle et absolument jamais contestée de la productivité. La meilleure maintenabilité est représentée par une valeur de zéro et la plus mauvaise est représentée par une valeur de trois. Les différents projets Java d’où sont issus les points du jeu de données sont représentés.

Inutile d'investir 3 ans de recherche pour conclure à partir de cette figure que la taille d'une classe est le principal indicateur de sa maintenabilité. Lors de son doctorat, votre serviteur, que personne n'avait mis au courant, s'est intéressé à cette problématique. Il se trouve qu'un prédicteur basé uniquement sur le nombre de lignes de code obtient de meilleurs résultats que des experts humains évaluant la maintenabilité (Bertrand 2024, ch. 7.3). La logique est simple, selon le nombre de lignes de code de la classe Java (LOC) :

1. Si LOC < 80 ⇒ Parfaitement maintenable
2. Si LOC < 275 ⇒ Maintenable
3. Si LOC < 500 ⇒ Non maintenable
4. Sinon ⇒ Pas du tout maintenable

Ce prédicteur vous permettra d'évaluer la maintenabilité de vos classes avec une grande fiabilité. Il n'est donc pas nécessaire de solliciter la précieuse expertise de vos architectes, probablement occupés à relire les écrits d'Ada Lovelace ou préparer leur dernière conférence sur Quarkus.

Un tel résultat peut paraître absurde ! En effet, cela voudrait dire que découper nos classes Java en plus petites classes suffirait à en garantir la maintenabilité. De ce point de vue, le couplage des classes entre elles ou la complexité algorithmique interne d'une classe n'a que peu d'importance.

Toutefois, si on se réfère au célèbre Clean Code de Robert C. Martin, on se rendra rapidement compte que de nombreuses règles concernent directement ou indirectement la taille :

Les fonctions doivent être petites ;
Le nombre idéal d'arguments d'une fonction est zéro ;
Une fonction ne doit faire qu'une seule chose ;
Les classes doivent être petites ;
Les classes doivent avoir un petit nombre de variables d'instance ;
Une classe ne doit avoir qu'une seule responsabilité.

Ainsi, il est logique que la taille soit un bon prédicteur de la maintenabilité logicielle. En effet, lorsque le développeur rencontre une difficulté, technique ou fonctionnelle, il peut s'égarer dans le code et ajouter un peu trop de fonctionnalités à une classe ou adopter une solution structurellement sous-optimale. Les développeurs n'écrivent pas du code pour rien ou pour le plaisir, une trop grande classe est le symptôme d'un problème sous-jacent qui impacte la maintenabilité.

Ainsi, au vu des résultats expérimentaux, il est possible de considérer la taille idéale d'une classe Java, c'est à dire d'une classe parfaitement maintenable qui implémente néanmoins un nombre optimal de fonctionnalités. Soit ω cette taille idéale pour une classe Java :

Évidemment, ceci dépend du langage de programmation. Par exemple, il est de notoriété publique que Python est beaucoup plus concis que la plupart de ses concurrents. Ainsi, Raemaekers (2015) compare les langages à l'aide de leurs taux de compression, c'est-à-dire la capacité à exprimer une intention complexe, et du nombre d'instructions par points de fonction, une mesure de la verbosité brute. Raemaekers (ch. 7.5.1) présente la table ci-dessous, traduite pour votre plus grand confort.

Il est particulièrement intéressant de considérer Python, langage de LA DATA et échafaud de nos intelligences artificielles. Au vu de son adoption météorique par les développeurs, il fait peu de doute que Python est le langage ultime. On peut alors se poser la question de la valeur ω pour ce dernier.

Le coefficient δ est un coefficient de conversion de verbosité fonctionnelle de Java vers Python. Il est possible de le formuler comme l'isobarycentre des ratios des taux de compression ξ et des ratios du nombre d'instructions par point de fonction ψ.

En se basant sur les valeurs empiriques du tableau, le coefficient δ peut être évalué.

En réinjectant le coefficient de conversion de verbosité fonctionnelle dans notre équation de conversion, nous obtenons la réponse à la question ultime :
Quelle est la taille idéale d'une classe ?

Post mortem : Toute ressemblance avec une démonstration mathématique complexe pour justifier une intuition que tout le monde avait déjà serait purement fortuite. Bien que tout soit véridique dans cet article, il souffre évidemment d'un biais de confirmation très prononcé… et cela a demandé beaucoup de travail !

Les européens ont-ils vraiment perdu la guerre du cloud ?

nicolasT — Mon, 22 Dec 2025 08:00:00 +0000

Le contexte géopolitique récent a relancé une question qui s'est posée à partir de 2013 : est-ce que les européens ont perdu la guerre du cloud ?
Autrement dit, peut-on se passer des hyperscalers américains pour travailler dans le cloud public ?

Nous sommes en 2025, qu'en est-il ?

TL;DR
Oui, ils ont perdus de nombreuses batailles... mais peut-être pas la guerre. La rebellion se réorganise.
L’IA est l’occasion de relancer une dynamique en Europe.
La solution pour les offres IaaS, PaaS, SaaS pourrait passer par une fédération des acteurs.

La naissance d’un empire

Quand on évoque le "cloud public", bon nombre, pour ne pas dire tous, pensent immédiatement aux trois mastodontes américains. La raison ? La puissance marketing de ces derniers. Il faut reconnaitre que sur cet aspect, les américains semblent avoir une culture marketing que les européens n’arrivent pas à rattraper. Ajoutez à cela l’admiration toujours présente de la Silicon Valley qui place ces acteurs comme les fers de lance de l’IT.

De leur côté, les européens paraissent avoir eu besoin de digérer cette nouvelle notion. Le cloud public n'est qu'une forme de maturité et une évolution du métier de l'hébergement Internet. Pourtant, ce terme marketing est vite devenu un élément différenciant pour les acteurs nord-américains. Les hébergeurs européens n’ont peut-être par perçu ce terme comme étant vecteur d’une évolution de leur métier.

Par ailleurs, le marché, bien qu’admiratif, ne s’est pas rué sur ces nouvelles offres. Dans les premières années, les DSI avaient du mal à se projeter dans ce nouveau paradigme : quel coût à la fin du mois, de l’année ? Comment maitriser mon infra ? L’IaC (infrastructure as code) et l’éducation ont répondu à ces questions, à grand renfort de meet-ups sponsorisés et/ou présentant des démonstrations s’appuyant sur AWS.

La seconde défaite européenne vient de la technologie. Là où les européens étaient très présents et sur un marché dynamique de l’hébergement Internet, les clouds sont arrivés avec une réponse technologique innovante : des API et des outils pour automatiser la gestion des infrastructures dynamiques. Dans le même temps, Heroku, encore un acteur américain, propose une solution allégée pour déployer les applications : un PaaS.

Certains acteurs européens ont tenté de suivre, voir rattraper les solutions : les initiatives ratées Cloudwatt et Numergy de l’État français ; la tentative de résistance du cloud gaulois ;
platform.sh, PCextreme B.V. (racheté par versio), Digital Ocean, etc. Toutes ces initiatives n’ont pas réussi à faire de l’ombre à l’hégémonie naissante du futur trio omniprésent du cloud public, bien que proposant des solutions cohérentes, tant au niveau technique que financier.

Le dernier rapport sur les parts de marché des fournisseurs de cloud du Synergy Research Group fait état de 63% occupées par le trio AWS, GCP et Azure. Derrière cette domination se trouvent d’autres acteurs, dont de grands noms de la tech américaine, ainsi que le fournisseur chinois Alibaba.

source https://www.srgresearch.com/articles/cloud-market-share-trends-big-three-together-hold-63-while-oracle-and-the-neoclouds-inch-higher

Derrière le terme "neoclouds" se trouvent de nouveaux acteurs : CoreWeave, Crusoe, Nebius et Lambda.

La menace fantôme

Technologiquement, les acteurs de l'hébergement français paraissent avoir raté le virage du cloud. OVHcloud, acteur incontournable en France et en Europe, propose peu de services concurrents à AWS, GCP et Azure. Ceux proposés sont arrivés tardivement et ne semblent pas leur permettre d'être vus comme alternative.

Pourtant, dès 2011, des acteurs de l'hébergement Internet se lancent dans la fourniture de services de cloud moderne. Ikoula propose des VMs avec une facturation à l'usage. Modèle clé des acteurs du cloud moderne, par lequel ils ont secoué le marché. Ikoula récidive en 2013 avec une offre plus complète basée sur CloudStack. À l'époque, Gandi lance une offre de VPS concurrente. OVH, quant à lui, tarde à lancer son offre basée sur OpenStack. Digital Ocean émerge, avec une stratégie marketing agressive pour séduire les développeurs. Platform.sh se propose comme alternative à Heroku. PCextreme se crée aux Pays-Bas en s’appuyant également sur CloudStack. Scality, qui se concentre sur le stockage objet, voit le jour en 2009, et lance un appel à une fédération d’acteurs, pour proposer rapidement une offre multizone.
Il y a certainement d’autres initiatives à mentionner. Cependant, aucune n’arrive à se frayer un chemin face à ce qui se trame outre Atlantique. Amazon fait cavalier seul, ou presque. Malgré un départ en deux temps, Google et Microsoft réussissent à combler leur retard.

Après s'être laissé dépasser / déborder par les américains, les européens se concentrent visiblement sur le marché public, sécuritaire et la régulation.

Un nouvel espoir

Le cloud souverain. Terme très utilisé parmi les régulateurs et autres personnalités politiques et représentants d’entreprises publiques. Le terme n’est pas nouveau, cependant, en France la première initiative (Cloudwatt et Numergy) fut un échec. Pardon, je devrais dire qu’elle n’a pas marché.
Fort de cette expérience, cette fois les acteurs existants du marché de l’hébergement Internet sont contactés, comme OVH ou Online (ancien nom de Scaleway). Concrètement, peu de choses en sort, mis à part des initiatives orientées réglementation :

Gaia-X. L’idée première de cette initiative : fournir un standard pour favoriser l’émergence d’infrastructures fédérées.
European Union Cybersecurity Certification Scheme for Cloud Services. Projet de loi définissant les exigences en matière de cybersécurité entre les différents membres de l'UE.
SecNumCloud. Qualification de sécurité délivrée par l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information).

Comme toute rébellion, les choses ne se passent pas aussi facilement que prévu. Il ne faut pas attendre longtemps avant de voir Microsoft, Google ou Amazon entrer dans les discussions autour de Gaia-X. Ce projet est un tel succès que nombreux sont ceux à en avoir oublié son existence. Eurostack est lancée pour tenter d’apporter une réponse plus concrète.

Les normes EUCS et SecNumCloud sonnent la seconde vague de cette rébellion. Deux normes pour une même raison, l’une européenne, l’autre française. Bien entendu, la norme française est la plus contraignante. Encore une fois, les solutions d’envergures sont apportées via un modèle législatif.

Est-ce suffisant pour faire basculer des parts de marché vers des acteurs européens ? Dans le cadre de solutions avec de fortes contraintes de sécurité et de gouvernance, certainement. Bien que, par leur nature, ces contraintes orientent d’elles-mêmes vers une offre dite souveraine. Encore que… la décision par dépit de la CNIL concernant le Health Data Hub montre que ce n’est pas si simple.

L’empire contre-attaque

Oui, le marché européen du cloud public semble se contracter vers des offres de niche avec des contraintes fortes de souveraineté. En France, des partenariats "souverains" avec les opérateurs américains sont créés : Bleu pour Capgemini / Orange avec Microsoft Azure ; S3NS pour Thales avec Google Cloud.

Tandis que le lobbying a fait son œuvre dans les commissions, la réponse technologique passerait par un aveu d’échec : nous avons trop de retard, alors créons une offre qui permettrait de fusionner les produits américains avec les contraintes légales françaises. Dans les deux partenariats, la promesse est que les données sont toutes hébergées en France, dans des datacenters opérés par des entreprises française. Pour ajouter une couche de confiance, les données sont chiffrées par des clés inaccessibles aux entreprises américaines parentes des solutions technologiques.

Sur le papier, ça ressemble à un accord avec le meilleur des deux mondes. Oui, mais... un rapport juridique à destination du Ministère fédéral de l’Intérieur allemand vient quelque peu confirmer mes doutes. Ces offres ne protègent pas vraiment des lois extraterritoriales américaines.

Le retour du Jedi (ou du jet AI)

Les pannes récentes chez AWS, Google, Azure et CloudFlare démontrent une forte dépendance mondiale envers ces acteurs. Certains ont eu une prise de conscience de cette dépendance et regardent les alternatives. Ces alternatives existent et ne manquent pas. Par contre, elles sont souvent méconnues ou ne couvrent pas tout le périmètre technique que peuvent proposer le trio dominant.

Mon analogie avec la trilogie Star Wars s’arrête, car nous n’avons pas un Jedi européen pour aider la rébellion à gagner cette guerre. Est-ce sans espoir pour autant ? Peut-être pas.

Ma vision des choses et qu’il faut continuer de faire confiance aux acteurs européens. L’Europe ne possède pas (encore ?) d’hyperscaler pouvant proposer toute la panoplie de services que l’on trouve chez AWS, GCP ou Azure. Pourtant, rien qu’en France il existe des offres cohérentes. OVH cloud et Scaleway, par exemple, progressent fortement sur cet aspect. Leurs API permettent un usage dans la logique IaC. NumSpot se présente comme un nouveau challenger intéressant et ambitieux. Outscale possède également un catalogue intéressant, bien que plus restreint. Mais est-ce bien important ? Qui a besoin de l’ensemble de ces solutions ?

Il faut peut-être repenser l’adoption du cloud en se rapprochant de l’usage dont on a besoin. Une autre vision serait d’opter pour une stratégie cloud hybride ou multi-clouds.

Les entreprises du continent asiatiques semblent plutôt se tourner vers leurs champions : Alibaba, Tencent, Huawei, etc. Leur socle technologique ? Des solutions open source, qui sont également utilisées chez les acteurs cités précédemments.

Par ailleurs, l’IA est venue mélanger les cartes. Même si le marché est encore une fois dominé par des entreprises américaines, les européens ne sont pas en reste, notamment avec le français Mistral AI.

Et si

Et si la solution européenne pour les offres IaaS, PaaS, SaaS passait par une fédération des acteurs ?
Nous sommes en 2025 et l’IaC est devenu un standard dans la gestion des infrastructures. AWS, GCP et Azure proposent des API pour administrer leurs produits. Les solutions européennes aussi. Dans une stratégie multi-clouds il ne serait pas si complexe de répartir sur infrastructure sur les différents fournisseurs. Bien entendu, cela peut poser des défis au niveau de la connectivité et des performances. Nul doute que les architectes chevronnés sauront trouver les réponses !
Restera le point contractuel et financier. À ce niveau, il faut peut-être regarder du côté des réflexions FinOps, certains outils permettent d’avoir une vision multi-clouds.

Cette stratégie ne va peut-être pas vous convaincre. Alors à grand minima, nous avons besoin d’une cartographie des services clouds, à la manière du landscape de la CNCF. Mais ce sera sûrement le sujet d’un autre billet, plus court, je vous rassure ;)

Se faire du pied… Sans se marcher sur les pieds : convergence entre test et accessibilité

Henri Gauffriau — Sun, 21 Dec 2025 08:00:00 +0000

Dans notre environnement de travail, nous avons la chance de pouvoir réunir sur nos projets des expertises complémentaires, trop souvent mises de côtés dans les contextes tendus, faute de temps ou de budget. C’est notamment le cas des tests et de l’accessibilité, encore trop fréquemment relégués au second plan alors qu’ils conditionnent directement la qualité, dont la robustesse et la durabilité des produits.
Une fois réunis sur un même projet, nous avons rapidement constaté que nos métiers partageaient de nombreux points communs. Une grande partie du travail d’un expert en accessibilité consiste à réaliser des tests de conformité, tandis que, pour l’équipe test… c’est littéralement le cœur de son métier de devoir vérifier la présence d’un élément.
Nous avons donc commencé à nous faire du pied, avant de nous interroger sur nos périmètres respectifs et sur la meilleure manière de travailler ensemble sans se marcher dessus.

Tests et audits d’accessibilité : deux approches complémentaires

Dans les projets dont l’objectif est de rendre les services accessibles, il existe souvent une confusion entre les tests d’accessibilité et les audits d’accessibilité. Ces deux démarches ont pourtant des objectifs distincts.

Test d’accessibilité, vérifier par petit pas l’utilisabilité pour tous

Les tests d’accessibilité accompagnent le développement d’une application pour garantir qu’elle reste utilisable par toutes et tous.
Les Quality Analysts (QA) les mettent en place manuellement ou automatiquement, les exécutent, puis assurent le suivi des correctifs si nécessaire, comme ils le feraient pour une anomalie d’ergonomie, un problème fonctionnel ou une erreur de calcul.
Ces tests permettent d’identifier, au fil de l’eau, les problèmes d’accessibilité détectables automatiquement ou testables sans expertise avancée. Une partie de ces tests repose sur les « Easy Checks », une série de vérifications simples qui assurent les bases de l’accessibilité : navigation au clavier, alternatives textuelles des images, hiérarchie des titres, cohérence des formulaires, etc.
Il existe des extensions navigateur et des outils permettant de détecter facilement les manques de conformité d’un site ou d’une application en matière d’accessibilité. L’équipe QA peut notamment s’appuyer sur :

«WCAG Color Contrast Checker» qui va permettre de vérifier que le contraste est suffisant et si non mettre en évidence ou cela doit être corrigé.
Une autre extension intéressante, «Assistant RGAA» qui liste les catégories (Image, Lien, Multimédia…) et les critères du Référentiel Général d’Amélioration de l’Accessibilité (RGAA). Elle donne entre autres les instructions pour tester et permet de mettre le critère sélectionné en Conforme, Non conforme…

Audit d’accessibilité, évaluer la conformité d’un produit

L’audit d’accessibilité, quant à lui, est une évaluation complète et structurée d’un site, d’une application ou d’un service numérique. Il vise à vérifier sa conformité vis-à-vis des normes d’accessibilité. En France, on utilise le RGAA, fondé sur les Web Content Accessibility Guidelines (WCAG).
Un audit RGAA consiste à analyser un échantillon représentatif de pages ou d’écrans pour vérifier le respect de 106 critères de contrôle, couvrant 13 thématiques : images, cadres, couleurs, multimédia, tableaux, liens, scripts, éléments obligatoires, structuration, présentation, formulaires, navigation et consultation.Chaque critère comprend en moyenne 2 à 3 tests. On estime que seulement 20 à 30% d’entre eux peuvent être automatisés. Bien que certains soient simples à exécuter, l’ensemble de la démarche demande une expertise spécifique et du temps.
Les audits sont donc longs à réaliser et mobilisent des ressources peu disponibles, surtout dans le contexte post European Accessibility Act. On ne peut généralement pas en mener plusieurs par projet.

Qui fait quoi ?

Réaliser des tests ou un audit uniquement en fin de projet n’est pas la bonne approche : les erreurs sont déjà présentes et souvent accumulées. Les corriger à ce stade devient coûteux et chronophage. Ainsi, il est pertinent de les exécuter tout au long du projet, ce qui permet de détecter les erreurs au plus tôt et d’éviter l’effet « boule de neige » des anomalies répétées.
C’est un peu comme dans le bâtiment : s’occuper de l’accessibilité une fois la construction terminée implique de casser des portes, d’ajouter des rampes ou des ascenseurs oubliés.
Une approche plus efficace consiste à intégrer les bonnes pratiques dès le début du projet — c’est ce qu’on appelle l’approche « Shift Left », qui vise à détecter et corriger les problèmes le plus tôt possible.
Un autre point essentiel : l’accessibilité est l’affaire de tous.
La vérifier dès les premières étapes du projet permet d’embarquer l’ensemble des équipes et d’ancrer durablement les bons réflexes.
Accompagnée par les experts accessibilité, l’équipe test intègre les tests d’accessibilité dans son panel habituel.
De son côté, l’équipe accessibilité réalise des audits intermédiaires pour identifier les problèmes non couverts par les tests classiques, puis un audit final en fin de projet.

Les bénéfices

Cette collaboration crée une véritable dynamique vertueuse :

Les deux équipes s’enrichissent mutuellement.
La culture du test apportée par l’équipe QA a permis aux experts accessibilité de gagner en efficacité, notamment sur l’automatisation.
L’équipe accessibilité, quant à elle, a permis aux QA de monter en compétence sur les enjeux d’accessibilité numérique. C’est une approche gagnant-gagnant, qui se traduit par :
Moins d’anomalies détectées en fin de projet ;
Une meilleure qualité globale du produit (performance, ergonomie, robustesse) ;
Une culture commune autour de l’accessibilité numérique ;
Et une économie de temps et de moyens à long terme.

En définitive, cette collaboration entre QA et experts accessibilité constitue une première étape indispensable. Elle pose les fondations d’un produit plus inclusif, mais ne garantit pas à elle seule une expérience réellement accessible. La conformité, aussi importante soit-elle, ne reflète qu’une partie de la réalité vécue par les utilisateurs.
C’est un peu comme dans le bâtiment : le fait d’avoir posé le plancher ne signifie pas que la maison est habitable.
De la même manière, atteindre la conformité ne garantit pas une accessibilité complète. L’enjeu va au-delà du respect des critères : il s’agit de comprendre les usages, de tester en conditions réelles en s’appuyant sur un panel représentatif, d’anticiper les besoins, et d’inscrire durablement l’accessibilité dans la culture du projet. C’est là que commence la véritable démarche d’amélioration continue.

Accroche philosophique dans le monde informatique.

Damien LG — Sat, 20 Dec 2025 08:00:00 +0000

Les ponts

Prenons comme définition simple de la philosophie la description suivante : "Ensemble des sciences et des disciplines ayant pour objet la connaissance rationnelle de la nature" 1.

La philosophie aujourd'hui ne se limite plus à quelques hommes barbus se demandant si la notion de vide a du sens, ni à deux trois chroniqueurs de plateau semblant pouvoir s'exprimer sur n'importe quel sujet n'importe quand.
La philosophie regroupe tout un ensemble de disciplines traitant de sujets tout aussi précis que variés. Que ça soit la philosophie de l'esprit, du langage, de la morale, politique ou encore des sciences, toutes ces branches travaillent à mettre en place des théories permettant de qualifier le plus justement possible le fonctionnement du monde et notre interaction avec.

Tout d'abord, il faut bien souligner que l'informatique se repose sur des concepts fondamentaux pour la philosophie occidentale que sont les mathématiques et la logique. Mais ce ne sont pas les deux seules disciplines que nous pouvons appréhender dans cet univers.
On peut déjà souligner qu'aujourd'hui l'informatique se déploie notamment sous formes de langages. PHP, Java, Rust, langage fonctionnel, langage objet, etc...

Mais qu'est-ce qu'un langage ? Qu'est-ce que permet et produit la notion de langage ? Quelles sont les règles qui permettent de catégoriser tel ensemble comme étant un langage ou non ? Quelles sont les typologies de langage ? Est-ce qu'il est correct de parler de "langage machine" ?

Au-delà de la terminologie, notre langage naturel et ses signifiants débordent sur le monde de l'informatique et son langage formel.
Le fait de nommer des composants "master/slave" ou "agent" n'est pas anodin: par leurs histoires, ces mots véhiculent un imaginaire et un certain ensemble de règles, de structures, de signifiants et d'organisations associés. Et si vous doutez de l'impact du langage sur nos structures, demandez-vous pourquoi nous sommes désormais tous des talents et non plus des employés ou des salariés.

Parce qu'au final la philosophie politique n'est pas très loin derrière. Quand nous soutenons l'open-source ou que nous mettons en place des licences restrictives, quand nous nous demandons qui a le droit de merger et sous quelles contraintes, quand nous définissons les responsabilités dans l'équipe, nous faisons de la politique.
L'organisation de la production informatique est effectivement politique au sens où l'on se demande qui est légitime à décider, qui est responsable de la production et comment nous nous organisons collectivement.

Bon, passons cette introduction ennuyeuse et allons chercher des cas plus concrets.

Le software craftmanship

Peut-on qualifier la production de code comme étant une forme d'art ?

Après tout, nous avons bien eu le courant du "software craftmanship" pouvant être traduit littéralement par "artisanat logiciel". Et lire le manifeste associé permet, à mon sens, de se rendre compte des réflexions à mener sur notre domaine et nos pratiques.

"Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus"

Qu'est-ce qu'un logiciel bien conçu ? Pourquoi parle-t-on de qualité logicielle ? Est-ce que répondre aux exigences du métier est suffisant ? Est-ce qu'il faut un minimum de test ? Peut-on calculer de façon objective cette qualité ? Beaucoup de proposition existent pour rationaliser l'évaluation de la qualité logicielle et se basent sur des critères techniques et objectivables tels que la longueur des méthodes.

Dans ce cas à quoi servent les commentaires ? Pourquoi nous prenons nous la tête sur le nommage de variables ? Peut-être qu'une partie de la qualité de nos productions réside aussi dans sa qualité esthétique. Dans la manière dont nous avons rangé notre code, l'avons organisé et l'avons présenté pour que ceux qui passeront après nous (ou nous-mêmes) puissent s'y retrouver plus facilement.

Mais si on commence à parler d'esthétique est-on toujours dans l'objectivité ? On parle de beau et d'art, domaines où l'on amène souvent sa propre subjectivité. Ce qui ouvre tout un nouveau débat, mais limite pour le moment notre capacité à juger objectivement la bonne conception d'un logiciel.

Ou peut être que nos logiciels doivent être perçus comme des œuvres collectives, dont les qualités résideront dans leurs capacités à être comprises, appréhendées, transmises et à évoluer dans le temps.

"Pas seulement l'adaptation aux changements, mais aussi l'ajout constant de la valeur"

Aïe. La valeur. Vous savez calculer la valeur de votre code vous ?
Combien vaut votre commit ? Quelle est votre valeur ajoutée ? Quelle est la valeur d'un logiciel ?

Cette question ne concerne pas uniquement le code, mais est une vieille question de philosophie politique et économique. Est-ce que la valeur se détermine par l'échange ? C'est-à-dire, est-ce que la valeur de mon code réside seulement dans le prix que les gens sont prêts à payer pour ?

La notion de valeur est rapidement entendue en son sens marchand et contractuel, mais dans ce cas tout code produit dans une relation marchande aurait exclusivement la valeur qui lui est financièrement attribuée. Un code de "mauvaise qualité" pourrait donc valoir plus qu'un code de "bonne qualité".

Que faire de l'open source dans ce cas ? Que faire du code produit sur son temps libre ? N'a-t-il aucune valeur ? Où est-ce que sa valeur sera un reflet de l'effort mis dans sa production ? Un reflet de la force de travail engagé ?

Et de la valeur pour qui ? La question de la valeur de notre production technique peut et doit s'inscrire dans une réflexion plus générale sur le système de production. Nous ne pouvons pas extraire notre domaine du fonctionnement général de la société.

Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels

Alors comment définir le terme "professionnels" ? Dans le sens le plus simple, on pourrait dire que l'on est professionnel à partir du moment où l'on en tire un revenu de la pratique. En ce sens, il suffit d'être employé à produire du code pour en être un professionnel.

Mais est ce suffisant ? Nous avons souvent en tête une certaine de notion de compétence quand nous utilisons la notion de professionnel. Alors quelles sont les compétences d'un travailleur de l'informatique ? Comment pouvons-nous les qualifier ?

Cette question a été mise en exergue durant la période de fort recrutement et de très fort afflux de reconversions dans ce secteur. Les formations proposaient une reconversion dans des temps restreints et la question devient donc : quelles sont les compétences nécessaires ?

Qu'est-ce qui fait de nous des développeurs ?

Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.

Re Aïe. La productivité. Je ne vais pas m'étendre trop sur le sujet, car ça rejoint le point sur la valeur et parce que j'ai déjà eu l'occasion de m'exprimer sur ce sujet (BOUM, auto promo, je suis influenceur).

Profitons pour passer sur le sujet chaud du moment, Le sujet qui fait vibrer les foules et les porte-monnaies.

Les LLM

L'apparition et le développement rapide des LLM me semble être aujourd'hui l'exemple le plus frappant d'une incapacité collective à s'arrêter 30sc pour réfléchir aux termes que nous utilisons et aux implications de nos choix.

Les IA sont elles conscientes ? Nous avons tous un avis très tranché sur la question. "Évidemment que oui, certaines IA ont menti", "Évidemment que non, elles n'ont pas d'âme !".
Alors que nous ne savons même pas qualifier correctement la notion de conscience. Si l'on considère la conscience comme une propriété émergente de tout un ensemble de fonctions, alors, on pourrait dire que oui. On pourrait argumenter que les opérations internes effectuées par les LLM produisent des effets similaires à nos opérations internes d'humain. Dans ce cas à partir de combien d'effets identiques serions-nous capables d'attribuer la notion de conscience aux LLM ?

Ou alors, nous pouvons avoir une approche plus dualiste et proche de "l'élan de vie" qui dirait que nous, humains, avons un "p'tit truc en plus" qui fait de nous des êtres conscients, que cela est lié à la notion de vie et que l'on ne peut pas décemment attribuer de la conscience à des machines.

Alors si vous trouvez que la notion de bien-être animal est déjà compliquée parce qu'on leur attribue désormais une conscience, attendez qu'on se pose sérieusement la question pour des systèmes qui parle comme nous.

La question est similaire pour la notion d'intelligence. Ces sujets sont traités, étudiés et si ce terme peut être pertinent il est cependant nécessaire de correctement le définir au préalable. Car les termes que nous utilisons et leurs signifiants sous-jacents ne sont pas neutres et construisent notre rapport aux objets.

J'aimerais aussi évoquer le rapport à la connaissance. L'épistémologie est la branche de la philosophie s'intéressant à la connaissance et à la capacité de dire "je sais".
Jusqu'à peu, l'une des particularités de nos systèmes informatiques était leurs propriétés fortement déterministes. À savoir que pour chaque donnée entrante les opérations effectuées étaient les mêmes et que la sortie serait toujours la même ou a minima toujours prédictible. Ça ne veut pas dire que nous n'introduisons pas une forme d'aléatoire, mais que cette partie est restreinte à certains cas d'usages.

Ce que cela signifie, c'est aussi que sans savoir le fonctionnement interne de chacune de nos librairies, nous sommes en mesure de descendre dans la structure interne pour en étudier et comprendre le fonctionnement, en tout cas dans un monde tourné vers l'open-source. Ainsi, le travail et la compétence du développeur ne réside pas uniquement dans la production du code, mais aussi dans la connaissance et la compréhension du fonctionnement interne des outils qu'il manipule. Nous sommes capables de nous approprier les données entrantes, observer leurs parcours dans notre système et en comprendre la sortie produite grâce à son interaction avec ce système.

Il faut rester vigilant et ne pas idéaliser non plus le développeur comme une entité tout sachante et maîtrisant l'ensemble de la chaîne. Nous sommes faillibles, nous partageons la connaissance, prenons des raccourcis et nous organisons comme nous pouvons pour construire notre connaissance, la partager et la faire évoluer.

Les LLM transforment notre rapport à cette connaissance. Car deux fois le même appel avec les mêmes données peuvent produire deux résultats différents. Parce que nous avons des difficultés à analyser le fonctionnement interne ayant produit le résultat.

Nous nous mettons petit à petit à déléguer la connaissance aux LLM sans même interroger l'origine de leurs connaissances. Et si le LLM se trompe ? Est-ce que ça a seulement du sens de dire qu'un LLM se trompe ? Qui oriente les modèles ? Quelles sont leurs gestions ? D'où vient la donnée ?

Nous intégrons cette technologie fabuleuse à toute vitesse parce que "il n'y a pas le choix" en évacuant le processus démocratique et de réflexion nécessaire à l'intégration de ce type de technologie et leurs impacts considérables sur notre organisation sociale. Nous avons passé ces deux dernières décennies à travailler et sensibiliser sur la collecte de données, les usages et détournement qui en sont faits pour, du jour au lendemain, nous jeter collectivement dans les bras de ces mêmes entreprises et en leur offrant nos données sur un plateau d'argent quand elles ne viennent pas directement les récupérer sans poser de questions.

Si l'évolution des LLM est indéniable, si les LLM sont probablement des outils dont on commence à peine à appréhender les possibilités, il n'est pas nécessaire pour autant de tomber dans le mysticisme religieux.

Pour terminer et boucler avec le début de cet article, les Large Language Model sont, comme leur nom l'indique, des modèles de langage. Et si il vous semblait quelque peu folklorique de faire le parallèle entre langage et C++ je vous invite à reconsidérer cette pensée dans ce nouveau contexte.

Conclusion

La philosophie n'est pas qu'un moyen de se faire mousser à peu de frais et de paraître plus important que nous le sommes en citant des auteurs que nous ne comprenons pas. C'est un outil d'appréhension du réel et de mise en valeur des enjeux et implications de chaque possibilité d'interprétation.

Philosopher sur l'IA et l'informatique, c'est prendre ces sujets au sérieux. Comprendre leurs implications et la façon dont nous nous inscrivons dans cette chaîne. Que faire du travail quand le cœur de ces technologies est de nous en soulager ? Comment organiser ce système quand nous en faisons l'un des piliers du fonctionnement de notre société ?

Je ne suis pas philosophe et tout ce que je viens de dire doit être pris avec précaution, mais je suis un acteur, producteur du monde informatique et il me semble qu'il est de notre responsabilité d'utiliser notre compréhension de ces technologies pour proposer un débat public éclairé et constructif.

Si nous considérons vraiment ces technologies comme révolutionnaires, alors il nous faut penser la révolution.

Ressources diverses :

Release everything with JReleaser

Kosmik — Fri, 19 Dec 2025 13:03:32 +0000

JReleaser

The quick and effortless way to release your project!

Java, Go, Node, Rust, Zig, Swift, Perl, Python, C/C++, C#, Elixir, Haskell, Ruby, Crystal, and more.

— Official tag line

JReleaser is a tool that performs the most common steps related to releasing your application.

Releasing is not just about publishing a package to an artifact repository. It could also mean signing and generating artifacts, assembling and publishing a changelog, announcing the release on your favorite hub, and even making some noise about it through mail, Zulip, or whatever you want.

In this post, we will focus on releasing a Java application.

Wait, it's not just Maven 🫘!

Each packager, each artifact repository has its own specificity.

As Maven Central is the ultimate goal for Java developers, and as it’s also one of the most complicated repositories, this is the one we will be looking at in this blog post. But of course, once you’ve done that, everything else will be a piece of cake 🧁!

Pre-requisite (tools ⚒️ and credentials 🔐)

PGP

Generate your PGP key pair

gpg --generate-key

That will prompt the following

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: directory '/root/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/4C2428BC373276273A30B9D4FA30C263300AD893.rev'
public and secret key created and signed.

pub   ed25519 2025-11-18 [SC] [expires: 2028-11-17]
      4C2428BC373276273A30B9D4FA30C263300AD893 <1>
uid                      Guess who's back ? <back_again@shady.com>
sub   cv25519 2025-11-18 [E] [expires: 2028-11-17]

This is your key identifier; keep it somewhere.

You’ll be asked for a passphrase to protect your keypair. Choose wisely, and don’t tell anyone

If you forget to save your key identifier, you can find it back using the list-keys command :

just show me !

# gpg --list-keys
/root/.gnupg/pubring.kbx
------------------------
pub   ed25519 2025-11-18 [SC] [expires: 2028-11-17]
      4C2428BC373276273A30B9D4FA30C263300AD893
uid           [ultimate] Guess who's back ? <back_again@shady.com>
sub   cv25519 2025-11-18 [E] [expires: 2028-11-17]

Distribute it 🔑

There are sereval public keyservers and amongst them the following are supported keyserver.ubuntu.com, keys.openpgp.org, pgp.mit.edu.

The following command will make your key publicly available :

gpg --keyserver keyserver.ubuntu.com -send-key 4C2428BC373276273A30B9D4FA30C263300AD893<1>

Replace with your own key

Obtaining your maven central credentials.

You can specify its name and expiration date. Personally, I chose to go crazy for this :

Install JReleaser

There are many ways to install JReleaser, but my goto for local environment is to use JBang :

// Download, and install localy
jbang app install jreleaser@jreleaser

// Execute by using
jreleaser <command> [<args>]

If you prefere to run it without installing it, you can also use JBang :

// Download, cache, and run
jbang jreleaser@jreleaser <command> [<args>]

Verify your project descriptor

Even though JReleaser will do it for you, you can always independently verify if your project descriptor has all the mandatory fields to be published by running :

jbang pomchecker@kordamp check-maven-central

Please correct your descriptor accordingly and repeat the operation until everything is clean

Configure your project

This is a 2 steps process. You need to configure JReleaser but also your build process to generate all the necessary artefacts for publication.

The Maven configuration

Add a release profile to your pom.xml :

release profile

<profile>
    <id>release</id>
    <properties>
        <altDeploymentRepository>
            local::file:./target/staging-deploy ①
        </altDeploymentRepository>
    </properties>
    <build>
        <defaultGoal>deploy</defaultGoal>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <executions>
                    <execution>
                        <id>attach-javadocs</id>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                        <configuration>
                            <attach>true</attach>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-source-plugin</artifactId>
                <executions>
                    <execution>
                        <id>attach-sources</id>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                        <configuration>
                            <attach>true</attach>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

You can of course change this value

The Gradle configuration

If you do use Gradle, I’m sure you know how to produce the equivalent configuration. I don’t.

The JReleaser configuration

You can initialize your project configuration with the following command :

jbang jreleaser@jreleaser init

This will generate your project configuration file that you will have to amend following your needs.

jreleaser.yaml

# Generated with JReleaser 1.21.0 at 2025-11-19T09:09:25.55515446Z
project:
  name: app
  version: 1.0.0-SNAPSHOT
  description: Awesome App
  longDescription: Awesome App
  authors:
    - Duke
  license: Apache-2.0
  links:
    homepage: https://acme.com/app
  languages:
    java:
      groupId: com.acme
      version: 8
  inceptionYear: 2025

release:
  github:
    owner: duke

distributions:
  app:
    artifacts:
      - path: path/to/{{distributionName}}-{{projectVersion}}.zip

The distributions and github can be removed if you only want maven deployment, anyway you have to specify the maven deployment configuration by adding the following to your config file :

signing: ①
  active: ALWAYS
  armored: true

deploy: ②
  maven:
    mavenCentral:
      release-deploy:
        active: RELEASE
        url: https://central.sonatype.com/api/v1/publisher
        stagingRepositories:
          - target/staging-deploy ③
    nexus2:
      snapshot-deploy:
        active: SNAPSHOT
        snapshotUrl: https://central.sonatype.com/repository/maven-snapshots/
        applyMavenCentralRules: true
        snapshotSupported: true
        closeRepository: true
        releaseRepository: true
        stagingRepositories:
          - target/staging-deploy ③

Lets JRelease do the artefact signing for you
Which maven repository to use for release and snapshot deployments
Where to find the artefacts locally. Must match the value used in your project configuration.

You will have to specify a few secret variables, but for obvious security reasons, NOT in a versioned source file...

Specifying variables

Most of the JReleaser needed credentials are gonna be common for all your project. So setting them globally for JReleaser is a good thing to do. I set them in the JReleaser defaut folder. By default $HOME/.jreleaser/config.properties (accepted formats are PROPERTIES, YAML, TOML and JSON)

For more on this.

I choose TOML and here what my file looks like :

~/.jreleaser/config.toml

JRELEASER_GPG_PUBLIC_KEY = """-----BEGIN PGP PUBLIC KEY BLOCK-----

<place_your_public_key_here>
-----END PGP PUBLIC KEY BLOCK-----""" ①
JRELEASER_GPG_SECRET_KEY = """-----BEGIN PGP PRIVATE KEY BLOCK-----

<place_your_secret_key_here>
-----END PGP PRIVATE KEY BLOCK-----"""

JRELEASER_DRAFT = true ②
JRELEASER_GPG_PASSPHRASE = "❤️ Eminem<3<3"
JRELEASER_MAVENCENTRAL_RELEASE_DEPLOY_USERNAME = "redacted"
JRELEASER_MAVENCENTRAL_RELEASE_DEPLOY_TOKEN = "redacted"
JRELEASER_NEXUS2_SNAPSHOT_DEPLOY_USERNAME = "redacted"
JRELEASER_NEXUS2_SNAPSHOT_DEPLOY_TOKEN = "redacted" ③

Toml supports multiline string using triple double quotes: """
I only do draft release from local env
Values obtained in obtaining-your-maven-central-credentials chapter. They are the same for maven central and nexus2_snapshot

One more thing, please. I prefere to only do dry run execution locally but that cannot be specified through file at the moment, so I export the value just before running the commands :

export JRELEASER_DRY_RUN=true && jreleaser full-release

Once you’re happy, you can possibly unset the dry run property and relaunch, but I’d rather do the proper release from my CI, which is Github for me at the moment.

Running all this from Github actions

Here is the minimal github workflow to release a maven application.

name: Release
on:
  workflow_dispatch: ①
    inputs:
      version: ②
        description: "Release version"
        required: true

jobs:
  build:
    needs: [ precheck ]
    name: 'Build artefacts'
    runs-on: ubuntu-latest
    steps:
      - name: 'Check out repository'
        uses: actions/checkout@v4
        with:
          ref: ${{ needs.precheck.outputs.HEAD }}
      - name: 'Set up Java'
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 21
          cache: 'maven'
      - name: 'Build artefacts'
        run: mvn -B -P release clean deploy
      - name: Deploy to Central
        uses: jreleaser/release-action@v2 ③
        with:
          version: latest
          arguments: 'full-release' ④
        env:
          JRELEASER_GPG_PUBLIC_KEY: ${{ secrets.GPG_PUBLIC_KEY }}
          JRELEASER_GPG_SECRET_KEY: ${{ secrets.GPG_PRIVATE_KEY }}
          JRELEASER_GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}
          JRELEASER_MAVENCENTRAL_USERNAME: ${{ secrets.SONATYPE_USERNAME }}
          JRELEASER_MAVENCENTRAL_PASSWORD: ${{ secrets.SONATYPE_PASSWORD }}
          JRELEASER_NEXUS2_USERNAME: ${{ secrets.SONATYPE_USERNAME }}
          JRELEASER_NEXUS2_TOKEN: ${{ secrets.SONATYPE_PASSWORD }} ⑤
          JRELEASER_PROJECT_VERSION: ${{ github.event.inputs.version }} ②
         #JRELEASER_DRAFT: true ⑥

Manually triggered workflow
The version to be released. It could also be retrieved from your maven project.
Uses the JReleaser github action (Integration also exists with Gitlab, Gitea and many others)
Runs the full-release workflow
All the values to be assign in your project secrets
Wether or not do you want draft releases.

Wrap up

We’ve only scratch the surface of what can be done with JReleaser. If you want a really full example, here’s how JReleaser releases itself, with JReleaser of course.

But at least you know how to publish your artefacts to Maven Central 🗻 \o/ .

Diagram as Code en 2025 : Le repas de famille des outils

Alexis — Fri, 19 Dec 2025 06:00:00 +0000

Le 'Diagram as Code' : pourquoi et comment en 2025 ?

En tant qu'architectes, nous sommes confrontés à un défi récurrent : présenter un système de manière claire et maintenable sans y consacrer un temps infini.

Notre joli gribouillis finit généralement sur une porte de frigo, admiré à quelques cérémonies matinales de standup meeting (au mieux), puis oublié dans une boite mail.
Rarement tenu à jour, figé dans le temps tel une peinture rupestre de nos architectures primitives, parfois redécouvert au gré des fouilles de futurs archéologues.

Votre superbe diagramme d'architecture a un défaut majeur : à la seconde où vous l'exportez en PNG, il est déjà en voie d'obsolescence.

En 2025 j'ai expérimenté quelques solutions de diagramme as code, dans l'objectif de trouver le meilleur ensemble de qualités pour mes missions d'architecture. Je vous ferai ici une synthèse de mes expérimentations.
Chaque outil proposant un compromis différent, et chaque situation ne se prêtant pas à tous les compromis, vos conclusions pourront bien sûr diverger.

Mon ambition est de vous démontrer que ce passage au code n'est pas qu'une mode technique ou une régression vers l'artisanat, mais une évolution nécessaire vers plus de rigueur et d'expressivité. L'écosystème a mûri : les outils actuels nous permettent enfin de combler le fossé entre la théorie du tableau blanc et la réalité du terrain, pour peu qu'on apprenne à leur parler.
Et j'espère vous convaincre que le code est désormais le vecteur privilégié de la schématisation des architectures, tout comme le cloud a enfoncé la porte de l'Infrastructure as Code.

Un objectif : partager, ou comment la méthode amplifie nos capacités d'expression

Revenons un peu en arrière : comment matérialiser la pensée et l'échanger ? Par le langage bien sûr.
Si le visuel montre, le langage démontre. Il est le support premier de la pensée structurée. Ainsi pourquoi ne pas commencer par le langage au lieu de se lancer dans une représentation artistique ?

Sommes-nous condamnés à le réduire à de simples carrés et des flèches, là où les mots offrent une sémantique infiniment redéfinissable ?
En interprétant le code, la machine nous impose une syntaxe explicite, dissipant les flous du langage naturel.

Dès lors, pourquoi ne pas la laisser calculer les représentations optimales par une interprétation rigoureuse, plutôt que de nous épuiser en tâtonnements manuels et approximations graphiques.
Ce que nous verrons, c'est que le code permet aujourd'hui de produire (plutôt) aisément des représentations calculées, adaptables, reproductibles et intégrables à nos processus de traitement automatiques.

Structurer la pensée

Ce premier point est aujourd'hui assez généralement accepté : nous documentons nos systèmes, partageons dans nos langues, pour structurer une connaissance reproductible chez le collègue, l'organisation à laquelle nous prenons part, mais aussi le futur soi.
Le diagramme permettra de traiter de systèmes trop vastes pour être appréhendés d'un seul bloc, en explicitant les relations entre les éléments.
Par cet exercice, nous faisons émerger des informations parfois implicites dans une expression explicite.

Ce que l'on conçoit bien se modélise sans effort 😉

Le passage au diagramme constitue un test de cohérence : l'échec de la représentation visuelle trahit souvent une lacune dans l'analyse fonctionnelle, qu'il faudra combler ou non, selon nos objectifs (on en reparle plus bas).

Standardiser la communication

Une pensée structurée "s'imprime" d'autant plus facilement que sa forme est intuitive, proche de notre culture ou nos standards.
En utilisant des langages explicites, comme UML ou ArchiMate, on s'assure que "cette forme de carré avec cette couleur et ce symbole" veut dire la même chose pour tout le monde.
Mais ces deux standards peinent encore à s'imposer : bien qu'apportant des éléments de rigueur intéressants, leurs outils manquent d'utilisabilité et de progressivité.
Et c'est au moins un état de fait auquel tout le monde s'accordera : en 2025 nous ne partageons toujours pas de lingua franca pour schématiser au quotidien. Nous nous en remettons souvent au tableau blanc avec une sémantique improvisée.
Cette improvisation génère une dette de communication : chaque nouvel arrivant doit réapprendre le dialecte de la tribu, et le diagramme est conçu comme un artefact personnel, non reproductible.

Pour que la standardisation soit effective, elle nécessite adoption, et l'adoption est nécessairement progressive : généralement par le contact répété avec un outil suffisamment intuitif.
Certains langages sont restés abstraits et peu répandus car conçus comme des idéaux, sans soucis d'ergonomie intrinsèque pour en développer l'utilisabilité, et leurs outillages butent aujourd'hui sur l'héritage de cette complexité.

Gérer la complexité par la séparation des enjeux : l'abstraction

Les langages sont suffisamment complexes pour qu'on se permette d'économiser un peu de précieux cortex cérébral, en traitant avant tout les priorités et des objectifs.
Nous éliminerons donc bien volontiers les détails inutiles pour nous concentrer sur les composants essentiels.

Ici l'expérience de méthodologies sera utile. Et pour cela, citons le TOGAF, qui explicite certains concepts clés :

La Vue (View) : ce que l'on voit réellement (le diagramme spécifique d'un système donné).
Le Point de Vue (Viewpoint) : la "perspective" ou la grille de lecture. Il définit pour qui on dessine et pourquoi. Ceci permet par exemple de présenter les informations à des publics différents selon les enjeux.

"Imaginez un bâtiment (le Modèle). Le plan électrique est une Vue destinée à l'électricien (Point de vue), tandis que le plan de façade est une autre Vue pour l'architecte des Bâtiments de France."

Nous pouvons imaginer un unique modèle, avec séparation de ses objectifs (points de vue) et de ses représentations (vues).
Et cela nécessite dès lors au moins trois langages :

Le langage pour Modéliser rigoureusement (e.g., langages spécifiques de modélisation).
Le langage pour représenter les Objectifs/Perspectives (les Viewpoints TOGAF par exemple).
Le langage Visuel d'interprétation (UML, C4, etc.)

Vous conviendrez que trois langages, c'est beaucoup à apprendre. Profitons un peu de nos machines pour nous faciliter le traitement.
Le "code" du Diagram as Code visera précisément à fusionner ou simplifier les langages 1 et 2 pour que la machine gère le dernier.

La puissance cachée du Code : Intégration, Git et IA

Démystifions : le code n'est qu'un langage, dont la seule vertu est d'être formalisé, c'est à dire que sa structure est régulière : simple, non contextuelle, sans ambigüité, pour en permettre le traitement procédural par nos petits amis les ordinateurs.

L'usage du code est donc avant tout de clarifier ce que nous attendons de la machine, et cela peut prendre des formes assez diverses. Certains d'entre vous auront développé en C#, Java ou encore Python…
Votre bagage de développement sera bien sûr un avantage d'aisance, mais pour produire des diagrammes nous limiterons un peu la richesse syntaxique et essaierons de maximiser l'expressivité sémantique, c'est-à-dire : utiliser peu de mots pour exprimer beaucoup.
L'objectif étant que nos machines sachent quoi nous montrer sans débats byzantins sur le sens des mots, en ayant peu d'effort d'explication à fournir.

C'est aussi là qu'un langage de code intuitif prendra toute son importance : des mots clairs pour des concepts que nous côtoyons déjà c'est quand même bien plus simple à prendre en main pour exprimer ce que l'on veut voir.

Intégration aux pratiques : Versionning et "Diffability"

Toute une industrie s'est construite autour du code et a abouti à des bonnes pratiques dont nous pouvons hériter. En utilisant du code, vous n'obtenez pas seulement une solution de dessin, mais tout un écosystème. L'avantage immédiat est la capacité à versionner avec Git, mais le véritable gain réside dans la "diffability" (la lisibilité des différences).

Contrairement à un fichier .drawio ou .archimate (souvent constitués de milliers de lignes de XML indigeste où le simple déplacement d'une boîte de trois pixels modifie 50 lignes de coordonnées), les langages de diagramme as code sont sémantiques.
Lors d'une revue de ce code, vous ne voyez pas seulement que le fichier a changé, vous lisez l'intention : une ligne rouge indique - user -> database, une ligne verte indique + user -> api -> database soulignant ce qui a été modifié.
L'évolution de l'architecture devient auditable ligne par ligne, permettant une véritable revue de conception asynchrone entre membres de l'équipe, avant même que le diagramme ne soit généré.

Intégration aux traitements automatiques

Mais ce format textuel ouvre surtout la porte à l'industrialisation via l'Intégration et le Déploiement Continus (CI/CD). Puisque vos diagrammes sont désormais des sources compilables, ils s'intègrent naturellement à vos pipelines de build (GitHub Actions, GitLab CI, etc.) au même titre que votre code applicatif.

Concrètement, imaginez qu'à chaque nouvelle fonctionnalité dans le code, votre traitement d'intégration vérifie la syntaxe, régénère automatiquement les rendus des diagrammes, et publie la mise à jour sur votre portail de documentation. Sans aucune intervention humaine, ou du moins elle devient limitée.
C'est la garantie d'une documentation vivante (Living Documentation), enfin synchronisée avec la réalité du terrain, mettant un terme définitif aux schémas obsolètes copié-collés manuellement dans des documents Word oubliés.

Diagramme aidé par IA

Et vous n'allez peut-être pas me croire mais récemment, ont émergé les… LLM et IA génératives !😉
Et leur spécialité, c'est précisément de générer du langage !
Je vous enjoins chaleureusement à tester leurs capacités. La qualité des ébauches générées est souvent bluffante ; il ne reste généralement qu'à les retoucher.
Exemple avec Mermaid : copiez votre classe Java ou votre description du système dans ChatGPT et demandez : 'Génère un diagramme de séquence Mermaid expliquant le flux de données de ce code'. Copiez le résultat dans le playground Mermaid : le résultat est immédiat.

Comment comparer

On peut dégager quelques critères de cette introduction au principe du diagramme as code.

Critères d'Adoption et d'Usabilité (Prise en main)

Ces critères sont primordiaux pour l'échange et la collaboration au quotidien.

Critère	Pourquoi est-ce important ?
1. Courbe d'Apprentissage	Facilité et rapidité pour une personne non familière avec l'outil à écrire un premier diagramme simple. Le DSL doit être intuitif et non verbeux. (Mermaid, D2) favorise l'adoption rapide, même par le non-développeur.
2. Facilité à se lancer	Rapidité à démarrer un nouveau diagramme sans devoir gérer une structure de modèle complexe au préalable, et des outils à installer parfois très techniques. Les outils orientés "scénario" ou "micro-diagramme" (Mermaid) sont excellents ici, contrairement aux outils orientés "modèle unique" avec une application serveur (Structurizr).
3. Qualité du Rendu	Un diagramme plaisant et clair est plus vendeur, plus partagé et plus souvent mis à jour.

Critères Techniques et Opérationnels (Intégration et Coût)

Ces critères sont essentiels pour la documentation et la maintenabilité.

Critère	Pourquoi est-ce important ?
4. Coût et Licence	Le coût d'utilisation de l'outil et de ses fonctionnalités (moteur de rendu, plugins, licences commerciales). Une solution open source ou gratuite favorise l'adoption à l'échelle de l'entreprise (PlantUML, Mermaid). Le coût de certaines fonctionnalités (e.g., Tala de D2) est un frein.
5. Intégration dans l'Écosystème cible	Disponibilité de plugins dans les outils quotidiens (VS Code, JetBrains, Confluence, GitHub/GitLab Markdown). Si l'équipe passe sa journée dans VS Code, un bon plugin PlantUML ou Mermaid est un must. Et une intégration aux produits IA/LLM, ça ne mangerait pas de pain !

Critères Sémantiques (Rigueur et flexibilité)

Ces critères jugent de l'équilibre entre la rigueur (TOGAF, C4) et le pragmatisme.

Critère	Pourquoi est-ce important ?
6. Rigueur sémantique flexible	Le niveau de formalisme absent ou imposé (note basse) ou supporté avec flexibilité (note haute). Il doit pouvoir être adapté au contexte pour ne pas nuire à la prise en main.
7. Réutilisabilité	Capacité à générer des vues filtrées à partir d'un unique modèle de référence qui peut être composé du travail de plusieurs contributeurs. Essentiel pour reformuler le même modèle à des publics différents sans redessiner, et pour collaborer brique par brique vers un système plus grand.

Petit arbre généalogique 2025 : présentation de quelques membres émérites

Alors le diagramme et la modélisation, ce n'est pas nouveau et il existe déjà quantité d'outils, plus ou moins accessibles et intégrables à nos vies déjà bien chargées.

👵 Mamie Archimate

"Archi is an open source modelling toolkit to create ArchiMate models and sketches. […] It is targeted toward all levels of Enterprise Architects and Modellers." Archi – Open Source ArchiMate Modelling

Documentation Officielle	Archi%20User%20Guide.pdf
Téléchargement de l'Outil	https://www.archimatetool.com
Fonctionnalité Clé	Analyse d'Impact : La capacité de tracer un lien de "Réalisation" depuis un serveur physique jusqu'à un objectif métier stratégique pour évaluer les risques
Démonstration	https://github.com/archimate-models/archisurance - Modèle complet de fusion d'entreprise Note : Archi est un client lourd (Desktop). Les modèles ne peuvent être visualisés en ligne. D'autres outils permettent de modéliser à la façon de Archi, et sont consultables en ligne, comme ces exemples PlantUML : [Archimate-PlantUML \

Mamie fait de la modélisation rigoureuse, trace au cordeau des architectures formelles et permet, à partir d'un modèle unique, de produire des vues sur le contenu selon les couches TOGAF.
Attention, ça ne devient intéressant que si l'on maitrise ses concepts et qu'on y produise un modèle exhaustif… Et séparer le modèle de la présentation, on l'a dit, c'est souvent bien pratique (MVC tu connais). Difficile en tout cas de s'y mettre progressivement, et pour débuter je vous conseille d'utiliser une antisèche.

Ma conclusion : si vous avez le temps de constituer un modèle bien à plat, c'est très puissant pour de l'architecture d'entreprise. Pour de l'architecture un peu moins abstraite, on aura du mal à trouver le temps de tenir ça à jour, surtout dans l'interface au clic…

✏️ Tata Draw.io/Diagram.net

"security-first diagramming for teams. […] You choose where to store your data. We don't store your diagram data." — Diagrams.net Main page

Documentation Officielle	https://www.drawio.com/doc/
Éditeur en Ligne	app.diagrams.net
Fonctionnalité Clé	Agnosticisme de Plateforme : Sauvegarde directe en XML, PNG, SVG ou HTML sur votre disque local ou repo Git, sans cloud intermédiaire.
Démonstration	Blog - Create a sequence diagram - Exemples variés (Réseau, UML, BPMN) sinon : Example draw.io diagrams and templates

L'outil de diagramme intégrable un peu partout, disponible gratuitement sur le web, avec un export PNG qui intègre le xml qui a permis de le générer, et qui peut donc être réimporté. C'est assez canon pour balader son dessin.
Son modèle de stockage est unique et constitue son "killer feature" pour les entreprises soucieuses de la confidentialité des données : l'outil adopte une approche "Bring Your Own Storage" (BYOS). Draw.io ne stocke pas vos diagrammes sur ses propres serveurs. Il agit comme une couche d'édition par-dessus vos fournisseurs de stockage existants : Google Drive, GitHub, OneDrive, Dropbox, ou simplement le système de fichiers local.
Elle dispose aussi d'une base d'icônes et de symboles gigantesques, ce qui n'est d'ailleurs pas toujours facile à naviguer.

Attention cependant, c'est tout au clic (ou presque) et il va falloir tracer des boites et des flèches en pagaille, puis tout réagencer.

Ma conclusion : Pour les artistes qui ne veulent aucune limite, et ne rien risquer de leurs données : ça fait tout. Mais il va falloir bricoler…

🖱️ Mama yEd

"yEd is a powerful desktop application that can be used to quickly and effectively generate high-quality diagrams. […] Its automatic layout algorithms arrange large data sets with just the press of a button." — yWorks Official Doc

Documentation Officielle	https://www.yworks.com/products/yed
Éditeur en Ligne	yEd Live (Version d'essai navigateur)
Téléchargement Desktop	https://www.yworks.com/downloads#yEd (Java Swing - version gratuite très limitée comparée à yEd Live !)
Fonctionnalité Clé	Disposition automatique : Transformer un chaos de 1000 nœuds en une structure hiérarchique lisible en un clic. Import direct depuis Excel.
Démonstration	https://www.yworks.com/pages/interactive-showcase-of-graph-layouts

Comme sa sœur Draw.io, il va falloir bricoler laborieusement : placer des petites boites et les contourner avec des flèches en clicodrome.
Ce dernier a au moins la présence d'esprit de structurer le dessin en hiérarchie (un graphe de noeuds xml), et de permettre (parfois) une disposition automatique avec son moteur d'arrangement.
Surtout si vous avez acheté une licence, coûteuse.

Ma conclusion : Si vous aimez cliquer, et avez le portefeuille bien rempli, ça peut être un bon outil mais peu confortable pour travailler avec efficience.

📜 L'ainé PlantUML

"PlantUML is an open-source tool allowing users to create diagrams from a plain text language. […] It can be used within many other tools." — PlantUML.com

Documentation Officielle	PlantUML.com
Téléchargement de l'Outil	https://plantuml.com/download ou Image Docker
Fonctionnalité Clé	Standard Library & Macros : Support étendu pour C4 Model et icônes Cloud (AWS/Azure) via inclusions `!include`.
Démonstration	https://www.planttext.com/

C'est le top et le pionnier de cette génération, si vous aimez les DSL exotiques et verbeux. Il fait le pont entre la génération parentale et la fratrie "as code" de la famille. Les cas d'usages intégrés sont extrêmement divers, l'outil est flexible à l'envie et permet de tout customiser jusqu'aux options de disposition du Graphviz sous-jacent.

Ses capacités sont très développées et gros point positif, il permet d'intégrer du code distant en le récupérant sur simple déclaration d'une URL, ce qui permet de réutiliser du PlantUML développé et diffusé par d'autres utilisateurs.
Pour les téméraires, il est possible de se créer des définitions prédéfinies pour normaliser les diagrammes selon vos pratiques, et de les généraliser assez simplement.
Par contre vous allez répéter des incantations toute la journée, et le résultat est souvent bien austère et peu vendeur. Je ne peux que vous conseiller de chercher des packs de styles pour le rendre plus appétissant.

Ma conclusion : Cet outil est un excellent précurseur, mais il ne s'est pas débarrassé de tous les défauts du diagramme "dessiné" et cumule ceux du as-code avec un langage construit par accumulation de concepts.

🧜‍♀️ Cousine Mermaid

"JavaScript based diagramming and charting tool that renders Markdown-inspired text definitions to create and modify diagrams dynamically." — Mermaid.js.org Intro

Documentation Officielle	https://mermaid.js.org/intro/syntax-reference.html
Téléchargement de l'Outil	NPM / GitHub (Mais souvent intégré nativement : GitHub, Notion, Obsidian)
Fonctionnalité Clé	Rendu Natif : Intégration transparente dans les fichiers Markdown (README.md) des plateformes de code (GitHub/GitLab).
Démonstration	Mermaid Live Editor

C'est intégré dans pas mal de lecteurs Markdown, c'est plutôt joli, mais contrairement à la génération dessin, il va falloir se contenter des cas d'usages prédéfinis : à la façon de PlantUML finalement, dont la sirène s'est certainement bien inspirée !
Le rendu est très propre tant qu'on ne rentre pas dans des graphes imbriqués un peu plus complexes.

Ma conclusion : Parfait pour des petits diagrammes (la généalogie ci-dessus) avec des cas d'usages assez divers et particuliers (modélisation GIT!) , et de la génération par IA avec une syntaxe relativement accessible.

🌊 Le cadet D2

"D2 is a domain-specific language (DSL) that turns text to diagrams. […] D2 is designed to be modern, hackable, and easy to read." — D2Lang.com Intro

Documentation Officielle	https://d2lang.com/tour/intro/
Téléchargement de l'Outil	Install Guide (CLI)
Fonctionnalité Clé	Moteur TALA & SQL : Moteur de disposition propriétaire optimisé pour l'esthétique et conversion automatique SQL vers ERD.
Démonstration	https://play.d2lang.com/

Celui-là c'est un sous-marin. Peu discuté dans mon entourage (malgré des étoiles ⭐ Github), il a le mérite d'être très abouti visuellement, et de fournir une syntaxe très simple et raffinée.

Avec son langage, il permet de définir des vues complexes composées selon trois modes : layers (couches), scénarios (variantes d'un même diagramme), et steps (déroulé) mais dont l'export est assez limité (diapositives de svg ou pages de pdf…).
Il propose aussi de sympathiques sélecteurs globsqui permettent d'ajouter des relations, des styles, des attributs sur le modèle défini, plusieurs éléments à la fois.
Enfin, il permet de composer du code avec des imports (syntaxe de chemin relatif vers un fichier par son nom) et des operateurs, ce qui peut s'avérer assez puissant pour composer à partir de diagrammes existants.

Il s'avère un peu moins bon pour modéliser à l'échelle d'équipes en collaboration, où l'on voudra des espaces de travail dans lesquels faire respecter des conventions communes, réemployer du code commun, pour obtenir une capacité à généraliser la représentation et cartographier précisément des systèmes de manière uniforme.

Son gros point fort (mais payant 🥲) c'est son moteur de disposition Tala : la structuration automatique des diagrammes est extrêmement puissante et démêle (vraiment) au maximum vos plats de spaghettis, tout en fusionnant les flèches et en alignant correctement sans déformations. Tout ça est développé pour l'IDE de diagrammes D2 Studio de Terrastruct, et distribué principalement en SaaS (onPrem possible) mais sous license.
Il permet aussi du contrôle sur la direction de chaque sous graphe, résolvant une des limites de Graphviz (et donc PlantUML).
C'est canon, mais ça coûte un peu cher, ce qui est généralement prohibitif pour l'adhésion par une équipe.

Un exemple plus orienté code :

Ma conclusion : D2 est l'un des outils les plus puissants, de par ses sélecteurs très flexibles et son rendu extrêmement propre. Il pèche un peu lorsque l'on passe en mode "projet" et que l'on tente de normaliser un peu nos divers diagrammes dans une base de diagrammes commune. À surveiller de près, mais son modèle de financement n'est pas idéal pour l'adoption.

📐 La benjamine Structurizr

"Allows you to create a software architecture model as code, and then visualize it using the C4 model. […] It's a way to create diagrams that are accurate and always up-to-date." — Structurizr.com

Documentation Officielle	https://docs.structurizr.com
Téléchargement de l'Outil	[Structurizr Lite \
Fonctionnalité Clé	Séparation Modèle-Vue : Définition d'un modèle unique (C4) permettant de générer automatiquement de multiples vues cohérentes.
Démonstration	https://structurizr.com/dsl

Celle-là, elle a de la suite dans les idées et elle monte tranquillement.
L'outil reprend strictement les concepts de l'architecture C4 (c'est développé par Simon Brown lui-même). On impose une séparation modèle/vue (mais pas contrôlable, c'est l'outil qui a ses vues type C4 fixées) et on sort une belle appli pour présenter notre système.

C'est joli, mais un peu restrictif. L'approche C4 est intéressante mais impose une sémantique essentialiste comme le fait ArchiMate, ce qui peut limiter les usages pratiques : il y a un gros travail intellectuel d'apprentissage et d'abstraction pour créer son modèle de données pour cet outil.
Pour définir des architectures et des systèmes de manière claire et simple, c'est excellent, mais difficile à intégrer (le résultat est dans une app entière) même s'il existe un générateur de site statique un peu primitif.

Ma conclusion: Gros potentiel, qui mérite encore un peu de maturation. Pas adapté aux pratiques d'architecture "maison", c'est un outil relativement rigoureux et qui propose de faire de l'architecture as code en intégrant aussi les Architecture Decision Records (ADR) par exemple.

👶 Le nourrisson prodige : Like C4

"Architecture-as-code tool. […] Look at your architecture as a single model and generate different views from it. LikeC4.dev Docs
Inspired by C4 Model and Structurizr DSL, but provides some flexibility. You customize or define your own notation, element types, and any number of nested levels in architecture model. GitHub - likec4/likec4

Documentation Officielle	https://likec4.dev/docs/
Téléchargement de l'Outil	• CLI : `npm install -g likec4` • IDE : Extension VS Code (LikeC4), et un tas d'autres IDE
Fonctionnalité Clé	Prédicats de Vue Dynamiques : Génération automatique de diagrammes interactifs à partir d'un modèle unique ("Single Source of Truth"), permettant de filtrer ou d'inclure des composants via des requêtes logiques.
Démonstration	Site de démo et example : https://likec4.dev/showcases/bigbank/

Ce qui distingue réellement le petit dernier, c'est son pragmatisme. Contrairement à Structurizr qui impose le carcan strict du C4, LikeC4 offre une typologie flexible. Mais sa vraie force réside dans la génération de prédicats.
Au lieu de dessiner manuellement chaque vue, vous dites à l'outil : "Affiche-moi le service 'Paiement' et tout ce qui interagit directement avec lui à deux niveaux de profondeur". L'outil calcule alors la vue optimale et les liens implicites.
Des métadonnées peuvent aussi être insérées un peu partout pour documenter les éléments et permettent de ne rien perdre de votre architecture, même si vous ne souhaitez pas afficher ces données directement.

De plus, LikeC4 génère des composants React natifs. Votre diagramme n'est pas une image statique (PNG), mais un composant web interactif que vous pouvez embarquer directement dans votre documentation technique (Storybook, Docusaurus, ou site propre). C'est le pont tant attendu entre le code vivant et l'architecture documentée.
Et contrairement à une image statique, et tout comme Structurizr : LikeC4 permet de "cliquer pour entrer" dans une boîte (en langage C4, passer du Context au Container, puis au Component). C'est le "Google Maps" de l'architecture, impossible à faire avec PlantUML ou Draw.io qui produisent des export statiques.

Dernier atout : MCP
Avec le Model Context Protocol (MCP), LikeC4 ne parle plus seulement aux humains, mais aussi aux machines. Cette fonctionnalité transforme vos diagrammes en une base de connaissance que vos assistants IA (comme Claude ou votre IDE) peuvent interroger. Votre compagnon IA peut interagir avec le modèle, vous accompagner et comprend désormais la structure réelle et les relations de votre système pour vous assister avec précision.

Attention toutefois aux limites de la jeunesse et du paradigme.
En tant que "nouvel arrivant" de la bande, LikeC4 souffre encore d'un écosystème plus modeste comparé aux standards de facto comme PlantUML. Si l'outil est open-source, parier sur un DSL (Domain Specific Language) jeune comporte toujours un risque de pérennité : si le maintien de l'outil s'arrête, votre base de connaissance architecturale devient orpheline, là où un fichier Mermaid est rendu nativement par GitHub ou GitLab sans outil tiers.

De plus, son approche purement "Code-First" érige une barrière à l'entrée non négligeable. Contrairement à un outil hybride, il exclut de facto les profils moins techniques (Product Owners, Business Analysts) de la contribution directe. Ils ne pourront pas "déplacer une boîte" pour corriger une incompréhension sans passer par un IDE et un commit Git. Enfin, sa grande flexibilité est une arme à double tranchant : là où Structurizr impose la rigueur du C4, LikeC4 vous laisse libre. Sans une discipline d'équipe sur le typage et le nommage, votre modèle "vivant" risque de devenir un "plat de spaghettis syntaxique", reproduisant dans la documentation la dette technique de votre code.

Ma conclusion :
Avec ses premiers commits en mars 2023, c'est du tout récent. Mais avec un rythme effréné : 163 releases, chacune apportant des petites nouveautés réjouissantes.
Cet outil m'a convaincu de le soutenir, et pour cause, j'y retrouve les principales qualités que j'attends d'un outil de diagram as code :

Un modèle unique pour une architecture, des vues customisables à loisir avec des sélecteurs
La capacité à partager une specification des éléments, et partager des éléments de modèles avec des include (encore un peu sommaire mais ça fonctionne)
Un potentiel explicatif énorme avec ses vues dynamique "séquence" que je vous invite à tester interactivement: c'est bluffant.

Comparons l'ensemble

Allez, petite photo de famille pour bien différencier tout ça. Et c'est plus facile à garder en souvenir !

L'évaluation devra être pondérée par votre contexte :

Si l'objectif est la collaboration rapide (tableaux blancs) : Les critères de prise en main et esthétique prennent le dessus. Mermaid ou D2 (sans Tala) sont d'excellents choix.
Si l'objectif est la documentation et la maintenance : Les critères opérationnels (technique et écosystème) sont les plus importants. Structurizr ou Like C4 sont plus adaptés.
Si l'objectif est la standardisation à l'échelle de l'entreprise (Rigueur) : Le critère de modèle et sémantique est essentiel. ArchiMate sera privilégié.

Tableau comparatif

Outil	Type	Prise en Main	Rigueur & Modèle	Atout Majeur	Usage Recommandé
✏️ Draw.io	Dessin	🟢 Immédiate	🔴 Nulle	Gratuité & Stockage (BYOS)	Schémas libres / Tableau blanc
🖱️ yEd	Dessin	🟠 Moyenne	🔴 Structure de graphe	Algorithmes de tri auto	Du schéma libre avec un peu d'automatisation
👵 ArchiMate	Modélisation	🔴 Très difficile	🟠 Très normative	Analyse d'impact & Normes	Architecture d'Entreprise
📜 PlantUML	Code	🟠 Difficile	🟠 Scénarisée	Écosystème immense	Ingénierie & Génération auto
🧜‍♀️ Mermaid	Code	🟢 Facile	🟠 Scénarisée	Support natif (Git/Notion)	Documentation de proximité
🌊 D2	Code	🟢 Intuitive	🟠 Libre	Esthétique & Moteur Tala	Présentations & Slides
📐Structurizr	Modélisation	🟠 Difficile	🟠 Normative	Séparation Vue/Modèle	Cartographie pérenne (C4 pur)
👶 LikeC4	Code	🟢 Intuitive	🟢 Flexible	Vues Dynamiques, prise en main progressive	Architecture Agile & Vivante

Ma recommandation

Aucun outil n'est donc encore pleinement satisfaisant pour tous les usages.
Je vous propose d'en utiliser plusieurs, de trouver ceux qui apportent un bon compromis d'approche en limitant la courbe d'apprentissage à l'aide de LLM, et en ne nécessitant pas trop d'investissement en formation au préalable.
Pour moi, c'est vers ceux-ci que je me tournerais :

Documenter les architectures en LikeC4 car il permet de partager quelques pratiques standardisées pour collaborer à l'aide de ses fichiers de spécification du modèle et ses imports entre projets. Le résultat est navigable et interactif, pratique pour partager avec le reste des équipes techniques et projet. Le tout progressivement. Vous pouvez commencer petit puis normaliser au fur et à mesure.
Les diagrammes plus opportunistes et brouillons : sur mermaid avec un LLM (Gemini ou Github Copilot font du bon boulot) et éventuellement sur D2 pour les cas un peu plus complexes.

Conclusion : Le retour du pragmatisme

Une petite matrice de conclusion (Merci Gemini pour cette dernière petite génération 😉 J'ai juste eu à ajuster les pondérations !)

Finalement, ne cherchons-nous pas simplement à démocratiser les concepts de TOGAF en les rendant enfin digestes ?

Le mouvement du Diagram as Code en 2025 n'est pas qu'une affaire d'outils ou de syntaxe. C'est une tentative de réconcilier deux mondes qui s'ignoraient : les développeurs (qui vivent dans le code) et les architectes (qui vivent dans les concepts).

L'outil parfait n'existe pas, mais la méthode parfaite commence par l'abandon du dessin manuel non-maintenable.
Commencez petit : un fichier Mermaid dans votre repo git décrivant effectivement le code est infiniment plus explicatif qu'un diagramme ArchiMate complet mais périmé en 2 semaines.

Enfin un pari pour l'avenir ? Les outils tout-en-un vont s'effacer au profit des outils de code, accompagnés de LLM.
Demain, cliquer sur une classe dans votre code ou un composant Spring générera la vue d'architecture LikeC4 correspondante en temps réel.
En attendant, à vos claviers !

Alors, ça prompte ?

damienb-opt — Thu, 18 Dec 2025 08:00:00 +0000

Qui n'a jamais croisé au hasard d'une déambulation dominicale ce fameux pêcheur, et lancé au passage un "alors, ça mord ?" Evidemment cela implique de quitter quelques minutes ses sombres écrans pour découvrir le monde de la très très grosse donnée, tellement riche que le pixel, même OLED, n'a plus de sens.

Pour ceux qui côtoient de réels collègues, pas ces succédanées d'interactions en "télétravail", il n'est pas rare de croiser de nouveaux pêcheurs 2.0, poussés par les hérauts des compétences molles à suivre une psychothérapie avec un canard en caoutchouc digitalisé. "Alors, ça prompte ?" est-on tenté de lancer !

Après tout, nous sommes sommés de devenir promptement des prompteurs. Et ce serait pêcher par orgueil de ne pas suivre cette voie disruptive. Qui n'a jamais rêvé d'être l'écran qui transforme le présentateur en simple lecteur ? Le prompteur ne serait qu'un lutrin ? Mais non, ça c'est la liseuse, qui n'a rien d'une lectrice !

Trêve de digressions et rentrons dans le vif du sujet : que se cache-t-il derrière cet apparent anglicisme ?

Les plus séniors d'entre nous se rappellent de leurs cours de BASIC, et du fameux INPUT. Dans An Introduction to Programming the Amstrad CPC464 and 664, il est écrit à ce sujet (je jaunis) :

The problem with the INPUT statement is that the simple question mark does not give any indication of what sort of input is required. To ease this problem, Locomotive BASIC has provision to include a line of text in the INPUT statement, which is printed on the screen along with the question mark, as an input prompt. When this is used, using a semi-colon between the prompt and the name of the variable will cause the question mark to be printed. Using a commas will cause it to be suppressed.

User-Friendly is a term that is much in use. It means making a program easy and pleasant to use. Input prompts are a vital part of this. They should clearly (and politely) indicate what the user is intended to type in. NAME? appearing on the screen would certainly indicate what is required, but is not very polite. “Please enter name” is better if the question mark is suppressed, otherwise “What is your name, please?” would be the best prompt to use.

One should avoid being obsequeous. If I came across an input prompt “Would you mind entering your name, please?” I personally could not resist entering NO!

It is very difficult to phrase input prompts to deal with multiple input statements, except at the very basic “enter three numbers” level.

Et bien, ça promptait sévère en 1985 il y a 40 ans !

Intéressons-nous à la traduction officielle de ce texte dans l'édition française du livre (je jaunis encore) :

L’instruction INPUT pose un problème : le point d’interrogation inscrit sur l'écran ne donne pas d'indication quant à la donnée demandée. Pour résoudre ce problème, Locomotive Basic peut insérer une ligne de texte dans l'instruction INPUT; cette ligne est inscrite avec le point d'interrogation. Lorsque l’on utilise cette possibilité, si on laisse un point-virgule entre la phrase et le nom de la variable, alors, le point d'interrogation apparaît. Sinon il est supprimé.

Les programmeurs amateurs adorent écrire des programmes distrayants et faciles d’accès ; l'emploi des lignes de texte définies ci-dessus occupent alors une place très importante. Elles doivent indiquer clairement ce que l’on demande à l’utilisateur. Si NOM ? apparaît sur l’écran, vous comprendrez très bien le sens de la question, mais il est plus poli d’écrire “indiquez votre nom s’il vous plait” ; dans ce cas, le point d'interrogation est supprimé, sinon “Quel est votre nom s’il vous plaît ?”, serait la meilleure possibilité.

Il faut toutefois éviter d’être pompeux : à la question “Auriez-vous l’amabilité de donner votre nom, s’il vous plaît ?”, il est difficile de résister à l’envie de répondre NON!

Il est très difficile de créer des phrases explicitant des instructions INPUT multiples, si ce n’est les très simples “Donnez trois nombres”.

Comment ça rien n'a été surligné ? Les mots input et prompt n'ont pas été traduits : la tournure des phrases a été légèrement modifiée pour éviter cet écueil. Mais que voulait dire prompter en cette année 1985 ? On peut regarder dans le Penguin English dictionary contemporain :

prompt: v 1 to move to action; incite 2 to assist (somebody acting or reciting) by saying the next words of something forgotten or imperfectly learnt

prompt: adj 1a ready and quick to act as occasion demands b punctual 2 performed readily or immediately

prompt: n the act or an instance of prompting; a reminder

On voit donc plusieurs sens. Pour l'adjectif, c'est le même que l'adjectif français prompt, qui vient du latin promptus. L'autre sens, celui de déclencher l'action, d'inciter, nous vient aussi du latin, d'un mot qui signifiait "mettre en avant", et que nous avons en français avec promouvoir. Quand au sens du souffleur, il est dérivé du fait que le prompter (en anglais) est toujours prêt (au sens de l'adjectif) à assister l'acteur.

Alors, comment fallait-il traduire ce prompt en 1985 ? Attend-on que l'utilisateur souffle une réponse à la machine, ou est-on en train de lui demander quelque chose ? On peut répondre promptement : input prompt, on demande à l'utilisateur sa saisie. Les traductions officielles ont depuis consacré le mot invite ou invitation pour cette demande. Quelque part, c'est un peu gentillet, dans le sens où dans ces IHM, si l'utilisateur ne saisit rien, l'ordinateur ne fait rien ; c'est plus un ordre, "rentre #LADATA dans moi (input) ou alors... je dors".

40 ans plus tard, on en est exactement au même point. Un programme attend bêtement qu'un humain vienne saisir de #LADATA. Et propose, en boucle, de recommencer. Après ces décennies par contre, on a oublié que c'était la même bête mécanique qui était en jeu, et on s'est senti obligé de la nommer avec un faux néologisme bien digital. Alors, ça prompte ?

DEV Community: Onepoint

Generating an aerial view of your project with OpenRewrite

The Need: Mapping Your Code

TL;DR;

The Mechanics: Analysis Without Modification

Going Further: Raw Export with Datatables

TNT 2026

Petit rappel sur TNT

L'évènement

Le lieu

Les soirées

Conférences

Keynote d'ouverture "Tech vs bots, débuggons la démocratie"

Onboarding 2.0 : Réinventer l'intégration des devs

Redécouvrir PHP : pratiques modernes au-delà de l’héritage

Title, ce faux ami de l'accessibilité

J'ai packagé mon application en image Docker, et maintenant ?

Fatigués de la POO ? Passer à la DOP !

Un jardin sur sol vivant connecté, pourquoi et comment ?

Open-source : Pourquoi ? Comment ?

Keynote de fermeture

Keynote ouverture : Gray hat, Black Hat, Users, Employés

Serveurs MCP au-delà des bases : bonnes pratiques, choix de conception et leurs conséquences

Tricher pour apprendre : 30 minutes par jour pour rester curieux dans nos métiers de la tech

Local-first et sync-engines, l'architecture du futur ?

Le mot de la fin : Une édition "Grand Cru" (Par Gemini)

Multi-Agent Platform with A2A, Python, Strands & AWS AgentCore

What we are building

Components

Runtime request flow

1 — Configuration (env vars)

HR Agent env

IT Agent env

Orchestrator env

2 — HR Agent handler (AgentCore Runtime + RAG)

Why os.environ["KNOWLEDGE_BASE_ID"] = KNOWLEDGE_BASE_ID?

What “RAG” means here

3 — IT Agent handler (AgentCore Runtime + RAG)

Why separate agents instead of one big agent with two KBs?

4 — Orchestrator handler (AgentCore Runtime + A2A tools)

Orchestrator key behaviors

Why implement HR/IT calls as tools?

5 — A2A call parsing

6 — Lazy initialization (production detail that matters)

7 — How routing actually happens

8 — Failure modes and debugging

Missing URL

Network/A2A issues

9 — Practical hardening ideas (optional)

Why this architecture scales

Final thoughts

RAG Works — Until You Hit the Long Tail

Why Training Knowledge Into Weights Is the Next Step Beyond RAG

The real problem is not the knowledge cutoff

Three ways to give knowledge to a language model

Full context: simple, expensive, and fragile

The transformer bottleneck and context degradation

RAG: external memory via embeddings

Why RAG is fundamentally limited

The naive fine-tuning trap

Synthetic data as the missing link

Training into weights without destroying the model

A hybrid future: context, retrieval, and weights

Conclusion

Guide d'apprentissage pour maîtriser GitHub Copilot

Table des matières

Partie I : Installation et présentation des fondamentaux (démarrage en douceur)

1.1 GitHub Copilot dans votre IDE vs GitHub Copilot CLI 🖊️

GitHub Copilot dans votre IDE

GitHub Copilot CLI

Comparaison rapide

1.2 Installer GitHub Copilot sur VS Code 🧩

1.3 Installer GitHub Copilot sur IntelliJ IDEA 🧩

1.4 Obtenir un compte GitHub avec accès Copilot 📝

Étape 1 : Créer un compte GitHub

Étape 2 : Activer GitHub Copilot

Alternative : Abonnement Etudiant (gratuit)

Étape 3 : Vérifier l’accès

1.5 Installer GitHub Copilot CLI 🚀

Prérequis

Why `os.environ["KNOWLEDGE_BASE_ID"] = KNOWLEDGE_BASE_ID`?