Alsacreations.com - Actualités - Archives (aout 2025)

Imaginez une scène sur laquelle le ou les artiste(s) n’utilise pas d’instrument traditionnel, mais des ordinateur sur lequel ils écrivent des lignes de code en temps réel qui donnent naissance à de la musique et des effets visuels projetés en live.

Bienvenue dans l'univers du live coding, et plus spécifiquement de l'Algorave, une subculture dans laquelle la programmation algorithmique devient une performance artistique et musicale !

Qu'est-ce que le Live Coding ?

Fait référence à une pratique d'improvisation musicale et/ou visuelle, généré avec des langages de programmations en directe.
Généralement, l’artiste partage son code au public en projetant son code sur une surface, il écrit et/ou modifie des algorithmes en temps réel au fur et à mesure de la performance.
On assiste alors à un processus créatif, qui montre l’esthétique, la logique et la beauté du code.

Le live coding, du fait de son histoire, est aussi un domaine de réflexion critique autour de notre rapport à l'informatique, à la technologie et à la culture numérique.

De nombreux live coders sont traversés par l'influence de la culture hacker, par les philosophies du logiciel libre et open source.

Cette pratique, mécaniquement, encourage à percevoir les logiciels comme des supports exploratoires ou conversationnels, et non seulement comme de simples outils pour la création.
Source : livecoding.fr

Source : Youtube - DJ_Dave & Char Stiles Livecoding Performance @ Algowave Algorave

L'Algorave

Le terme "algorave" est une contraction de "algorithme" et de "rave", ce qui est assez explicite.
L’algorave c’est l’événement où le "live coding" prend vie est où l’expérience est partagée avec le public ! Elle emmène le livecoding dans la culture de la fête et du partage.

Plus qu’un genre musical, l’Algorave est une pratique : une scène. Elle réunit des musiciens, programmeurs, hackers, artistes numériques et amateurs de musiques électroniques radicales autour d’un même postulat.

L’ordinateur n’est pas un outil caché, mais est au cœur de la scène et de la création.
Source : tsugi.fr

Un exemple vidéo vaut mille mots !

Source : Youtube - DJ_DAVE - GitHub Universe 2020

Vous souhaitez vous lancer dans l'aventure du live coding

Suivez le lapin blanc ! 🐇🕳️

Ma première réaction après avoir découvert, ça a été "Ok, trop cool, je veux essayer !”, Mais c’est écris avec quel langage de programmation ? Ils utilisent quoi comme outils !?

Après quelques recherches rapides, je découvre qu'il y a pleins de possibilité, mais ce qui revenait le plus souvent c'était TidalCycles basé sur Haskell qui permet d'écrire des motifs algorithmiques et SuperCollider avec SuperDirt qui gère la synthèse audio en temps réel souvent utilisé en backend pour le traitement audio.

La documentation est assez bien faite pour mieux comprendre et installer tout ça. Vous pouvez utiliser VSCode pour écrire vos premiers patterns et utiliser l'extension TidalCycles recommandé dans la documentation.

Il est aussi possible d'utilser du Python avec foxdot et toujours SuperCollider, un peu plus abordable que Haskell si vous avez déjà fait du Python.

Bref, vous avez compris il y a beaucoup à découvrir et à apprendre et je n'ai abordé que le côté musicale, car pour la partie visuel c'est pareil, c'est très, très vaste !
Mais rapidement je peux vous citer Orca ou gibber.

Bonus :

Directement dans votre navigateur web avec :

• strudel (à ne pas confondre avec la pâtisserie 😜) ! une version JavaScript de TidalCycles !
• hydra un synthétiseur vidéo en temps réel !

Source : Youtube - jam room @ London Algorave April 2025

Quelques ressources et liens

Si vous souhaitez aller plus loin, je vous partage quelques liens qui mon permis d'écrire cet article et de mieux comprendre cet univers.

Vidéos :

• Arte - Tracks
• La chaine Youtube @livecodenyc

Sites :

• Cookie Collective
• livecoding.fr
• algorave.com
• https://ressources.labomedia.org/live_coding

Reddit :

• r/livecoding
• r/Algorave

N'hésitez pas à partager d'autres ressources dans les commentaires et si vous êtes livecodeur partager vos créations ! 😃

Publié par Alsacreations.com

Il existe plusieurs façons de forcer le téléchargement d’un fichier côté navigateur, que ce soit pour un fichier statique déjà hébergé sur votre serveur ou pour des données générées dynamiquement (à la volée dans la page).

Utiliser l’attribut download

En ajoutant l’attribut download à une balise <a>, le navigateur téléchargera le fichier au lieu d’ouvrir le lien. C'est un attribut qui a été ajouté en HTML5, et qui est très bien pris en charge désormais, que ce soit sur mobile ou navigateurs desktop.

<a href="/chemin/vers/le/fichier" download>Télécharger</a>

Cet attribut est très pratique pour des fichiers statiques (PDF, images, etc.) mais que l'on souhaite proposer au téléchargement plutôt que de les "afficher" dans les onglets du navigateur.

En ajoutant une valeur à l'attribut download, on pourra préciser le nom du fichier qui sera écrit ou proposé dans la boîte de dialogue pour sauver le fichier localement, même si c'est un nom différent.

Simuler un clic par JavaScript

On peut créer un lien <a> dynamiquement (sans l'afficher), définir ses attributs, et finir par déclencher un événement click en JavaScript.

// Crée un nouvel élément <a> avec 
const link = document.createElement('a');
link.download = 'Recette-du-cake-au-kiwi.pdf';
link.href = '/recette-generator.php?kiwi';

// Ajoute l’élément au document
document.body.appendChild(link);

// Simule un clic
link.click();

// Supprime l’élément car il est désormais inutile 🧹
document.body.removeChild(link);

Cette technique est pratique si l’on veut déclencher un téléchargement à la suite d’une action utilisateur, sans disposer d'un lien explicitement visible et cliquable. Attention cependant à l'accessibilité d'une telle technique, qu'il faudra tester et à adapter à vos besoins.

Télécharger des données générées dynamiquement

On peut aussi vouloir télécharger des données produites côté navigateur, c'est-à-dire en front-end seul, sans que le serveur n'y soit pour rien. Cela peut résulter de données en JSON, texte, et même binaires en image, etc.

Pour cela, on peut

• transformer les données en Blob (voir aussi l'article sur les blob URLs)
• créer une URL temporaire avec URL.createObjectURL()
• utiliser la méthode précédente pour déclencher le téléchargement

Exemple avec un fichier JSON basique :

// Objet JavaScript brut
const obj = { recette: 'Rôti au kiwi', duree: 120, ingredients: 3 };

// Données à exporter converties en chaîne de texte
const data = JSON.stringify(obj);

// Crée un blob à partir des données
const blob = new Blob([data], { type: 'application/json' });

// Génère une URL temporaire
const url = window.URL.createObjectURL(blob);

// Crée un lien et déclenche le téléchargement
const link = document.createElement('a');
link.href = url;
link.download = 'data.json';
document.body.appendChild(link);
link.click();
document.body.removeChild(link);

// Libère l’URL temporaire et la mémoire 🧹
window.URL.revokeObjectURL(url);

Avec ces 3 petites techniques, vous pouvez proposer des téléchargements sans recharger la page dans le navigateur, par exemple dans le cadre d'une SPA.

Publié par Alsacreations.com

Choisir entre les balises <b>, <i>, <strong> et <em> est une question classique en développement web. La réponse ne se résume pas à un simple choix visuel. Pour écrire un code HTML sémantique, propre et pérenne, il est crucial de comprendre la nuance et l'intention derrière chacune de ces balises.

S'il ne faut retenir qu'une chose :

La sémantique avant tout ! <strong> et <em> donnent un sens au contenu. Tandis que <b> et <i> apportent une distinction visuelle sans changer l'importance du texte.

Si vous parcourez le web avec une synthèse vocale, celle-ci prendra une intonation différente en rencontrant <strong> et <em>. Mais pas avec <b> et <i> qui sont considérées comme "décoratives".

Sémantique ou présentation

Le code HTML a pour rôle de structurer et de donner du sens à votre contenu. Il indique ce qu'est un élément : un titre, un paragraphe, une liste, un texte important, etc.

Le code CSS, lui, a pour rôle de gérer la mise en forme et l'apparence. Il indique à quoi ressemble un élément : sa couleur, sa police, sa taille, son espacement.

Utiliser une balise HTML uniquement pour son effet visuel (par exemple, utiliser <b> parce que "ça met en gras") est une approche dépassée, mais souvent mal comprise car la balise <b> a toujours été pensée (et conservée) pour passer le texte en gras.

Les balises sémantiques <strong> et <em>

Ces balises informent le navigateur (et les technologies d'assistance comme les lecteurs d'écran) que le texte qu'elles entourent a une signification particulière.

<strong> : L'importance, le sérieux ou l'urgence

Utilisez <strong> pour marquer un texte qui a une grande importance. Ce n'est pas juste une suggestion visuelle ; vous affirmez que ce contenu est crucial. Les lecteurs d'écran peuvent changer d'intonation pour souligner cette importance.

Cas d'usage :

• Avertissements : <strong>Attention :</strong> Le sol est glissant.
• Instructions critiques dans un tutoriel : Il est <strong>essentiel</strong> de sauvegarder vos fichiers avant de continuer.
• Phrases clés qui résument une idée : En résumé, <strong>la collaboration était la clé du succès</strong>.

<p><strong>Avertissement :</strong> Ne débranchez jamais l'appareil pendant la mise à jour.</p>

<em> : L'emphase qui change le sens

Utilisez <em> pour mettre l'accent sur un mot ou un groupe de mots, de manière à modifier le sens de la phrase. Pensez à la façon dont vous changeriez votre intonation à l'oral.

Exemples :

• J'aime le gâteau. (Déclaration neutre)
• J'<em>aime</em> le gâteau. (L'accent est mis sur le sentiment, pas sur une simple appréciation.)
• <em>Moi</em>, j'aime le gâteau. (C'est moi, par opposition à quelqu'un d'autre.)

<p>Il ne faut <em>surtout pas</em> appuyer sur ce bouton.</p>
<p>Tu es sûr que c'est <em>toi</em> qui as vu ça ?</p>

Les balises de distinction : <b> et <i>

Contrairement à une idée reçue, <b> et <i> ne sont pas obsolètes en HTML (ou HTML5). Leur définition a été clarifiée : elles servent à différencier un texte du reste du paragraphe sans lui conférer une importance ou une emphase particulière. Elles sont utiles lorsque l'usage du gras ou de l'italique est une convention typographique.

<b> : Attirer l'attention

Utilisez <b> pour attirer l'œil sur un mot ou une phrase sans que cela implique une plus grande importance.

Cas d'usage :

• Mots-clés dans un résumé : Cet article explore les concepts de <strong>sémantique</strong> et d'<strong>accessibilité</strong>.
• Noms de produits dans une critique : Le nouveau <b>Pixel 9</b> est enfin disponible.
• La première phrase (ou lead) d'un article pour la faire ressortir.

<p>Les principaux langages du web sont le <b>HTML</b>, le <b>CSS</b> et le <b>JavaScript</b>.</p>

<i> : Texte idiomatique

Utilisez <i> pour un texte qui se distingue par sa "voix" ou sa nature. Il est par défaut présenté en italique.

Cas d'usage :

• Termes techniques ou taxonomiques : Le lion, Panthera leo, est un grand félin.
• Mots ou phrases dans une langue étrangère : Il a eu un deja vu étrange.
• Pensées d'un personnage : Que vais-je faire maintenant ?, pensa-t-elle.
• Noms de navires ou d'œuvres : Le Titanic a sombré en 1912.

<p>En français, le mot anglais <i lang="en">developer</i> se traduit par développeur.</p>

Récapitulons

Et si je veux juste du gras ou de l'italique ?

Que faire si vous voulez mettre un mot en gras ou en italique pour une raison purement décorative ou stylistique, sans aucune des justifications sémantiques ou conventionnelles ci-dessus ? Utilisez CSS. La balise <span> est un bon choix, elle est sémantiquement neutre et n'a pour vocation (dans ce cas) que d'appliquer des styles.

<p>Connecté en tant que <span class="username">Georges Moustaki</span>.</p>

.username {
  font-weight: bold;
}

Cette approche respecte la traditionnelle séparation : HTML (<span>) ne donne aucun sens particulier, et CSS (font-weight: bold;) s'occupe de l'apparence.

Publié par Alsacreations.com

Depuis l’arrivée du Full Site Editing (FSE) avec WordPress 5.8 en 2021, notre manière d’envisager la création de sites web évolue profondément ; l’architecture de création de thèmes et la gestion de la structure front-end ont profondément évolué. Dans cet article, on vous explique ce qu’est le FSE, pourquoi il change la donne, ses avantages et ses limites dans un contexte d’agence, et comment l’activer concrètement dans vos projets.

Le Full Site Editing (FSE) de WordPress

Le Full Site Editing (FSE) est une fonctionnalité de WordPress qui permet de concevoir et de modifier l’ensemble d’un site (en-tête, pied de page, templates, contenus) directement via l’éditeur de blocs Gutenberg, sans avoir à écrire de code PHP.

En clair : on ne passe plus uniquement par le back-office ou le code pour modifier un site, on travaille visuellement, par blocs, dans une logique modulaire.

Fichiers et dossiers essentiels

Conditions préalables : avoir un thème compatible FSE

Pour activer l’édition complète (FSE) sur WordPress, il est nécessaire de remplir deux conditions :

• Utiliser WordPress Version Récente : pour une utilisation optimale, il est recommandé d'utiliser la version 6.6 ou ultérieure de WordPress, car les fonctionnalités FSE sont en constante amélioration.
• Choisir un Thème Bloc Compatible FSE : il est indispensable de sélectionner un thème bloc (block theme) prenant en charge le Full Site Editing (FSE). Le thème Twenty Twenty Five est un excellent choix pour cela.

Le thème Twenty Twenty Five est spécialement conçu pour exploiter toutes les fonctionnalités de FSE. En utilisant ce thème, chaque aspect de votre site (page d'accueil, en-têtes, pieds de page, etc.) peut être modifié directement à partir de l'éditeur de site WordPress, rendant la personnalisation plus fluide et accessible.

L'Éditeur de Modèles (Template Editor)

L’une des fonctionnalités les plus puissantes de FSE est l'éditeur de modèles, qui permet de personnaliser les mises en page globales de votre site.

• Création de Mises en Page Personnalisées : avec l'éditeur de modèles, vous pouvez créer des mises en page personnalisées pour la page d'accueil, les archives des articles, ou même des modèles spécifiques pour des types de contenu particuliers.

• Gestion Visuelle des Modèles : les utilisateurs peuvent créer et gérer ces modèles directement via l'éditeur visuel intégré, ce qui rend la tâche beaucoup plus intuitive et accessible.

Les blocs prédéfinis et les Variations de Style

Le thème Twenty Twenty Five met à disposition des blocs prédéfinis qui simplifient la création et la gestion du contenu. Ces blocs sont conçus pour s'intégrer parfaitement à l'éditeur FSE.

• Blocs Prédéfinis Spécifiques à FSE : Par exemple, des blocs tels que Post Title, Post Content, Author Info, ou Featured Image sont disponibles pour être utilisés et personnalisés sur chaque page de votre site.

Pour un exemple concret : Avant FSE, les blocs comme Post Title ou Post Content étaient utilisés uniquement dans le contenu d'une page ou d'un article. Avec FSE et Twenty Twenty Five, ces mêmes blocs peuvent être utilisés dans des modèles de page, dans l'en-tête ou dans le pied de page. Cela permet une personnalisation globale de l'apparence et du contenu de chaque section de ton site, et non plus juste du contenu d'une page individuelle.

• Variations de Blocs : Twenty Twenty Five inclut également des variations de blocs, permettant de personnaliser rapidement des sections en appliquant des styles prédéfinis. Ces variations s'adaptent au thème et permettent de modifier l'apparence des blocs sans effort.

Structure des fichiers à prévoir pour un thème maison (stricte minimum)

Les fichiers requis pour un thème FSE sont similaires à ceux d’un thème classique, avec des ajouts spécifiques :

Cela garantit que votre thème sera prêt à prendre en charge toutes les personnalisations proposées par FSE.

Les atouts du Full Site Editing

Une approche modulaire plus rationnelle

Grâce à la logique par blocs, il est plus simple de créer des structures réutilisables, de normaliser les composants, et de proposer une base plus maintenable à long terme.

Productivité accrue pour les projets standards

Pour les sites simples, la combinaison FSE + thème block-based réduit drastiquement le temps de développement, en limitant le recours au code PHP.

Moins de dépendances externes

On s’affranchit progressivement des page builders lourds (coucou Elementor) ou de solutions propriétaires, avec un gain en performance et en pérennité : tout est natif et plus léger. Votre admin restera donc rapide, ce qui est très important si vous y passer beaucoup de temps.

Personnalisation en temps réel

Une autre grande avancée dans FSE est la possibilité de personnaliser le site en temps réel, ce qui veut dire que chaque modification apportée est immédiatement visible dans l’éditeur. Cela inclut non seulement les couleurs et typographies, mais aussi la structure des pages (ajouter ou déplacer des sections de blocs par exemple).

Structure versionnable et stockée dans des fichier

L’un des avantages majeurs du FSE, contrairement à d'autres thèmes builder, est que la structure du thème (templates, template parts, styles globaux, etc.) est désormais stockée dans des fichiers (.html, theme.json) et non plus uniquement dans la base de données.

Cela signifie :

• Meilleure gestion en versioning (Git)
• Déploiements plus propres et reproductibles
• Possibilité de travailler en équipe sans conflit lié à l’éditeur de contenu
• Restauration facilitée via des commits, et non via des exports SQL fragiles

Ce qu’il faut garder en tête

Changer sa façon de penser

Avec le FSE, on ne pense plus en pages statiques, mais en blocs dynamiques, organisés en modèles réutilisables. C’est une nouvelle grammaire pour les développeurs : pas de functions.php à tout va, mais des fichiers block-templates, un theme.json, et une logique HTML/CSS/JSON plus que PHP.

Pas encore optimal pour les projets complexes

Sur des projets sur-mesure avec logique métier poussée, l’approche FSE atteint ses limites. On continue à s’appuyer sur ACF, CPT, et du code PHP quand nécessaire.

Un écosystème en évolution

Certaines extensions (plugins) ne sont pas encore pleinement adaptées à cette nouvelle logique. Il faut vérifier leur compatibilité FSE dès la phase de cadrage.

Pour conclure, le thème Twenty Twenty Five est l'un des meilleurs points de départ pour exploiter tout le potentiel de Full Site Editing dans WordPress. Grâce à sa compatibilité native avec l’éditeur de site, il permet une personnalisation sans précédent des sites WordPress, même pour celles et ceux qui n'ont pas d'expérience avec le code. Il est conçu pour rendre l’édition de site accessible à tous, que ce soit pour les blogueurs, les entreprises, ou les designers.

👉 Et vous ? Avez-vous franchi le cap du Full Site Editing ?

Partagez vos retours d’expérience ou vos interrogations ! Discutons de ce que cette évolution peut apporter à notre métier.

Publié par Alsacreations.com

Le « vibe coding » est une expression inventée par Andrej Karpathy en début d'année, elle désigne une nouvelle façon de programmer, en déléguant entièrement l'écriture du code à l'intelligence artificielle d'un agent. Mais un agent de programmation IA reste un outil, apprendre à le manier demande un peu de temps et quelques efforts.

À qui s'adresse ce tutoriel ? À un développeur, utilisant Visual Studio Code, avec un abonnement GitHub Copilot payant, sur un projet existant.

Le plan gratuit ne suffira pas car nous aurons besoin des derniers modèles d'Anthropic. Ce tutoriel fait de plus l'hypothèse d'une base de code existante avec de préférence un système de gestion de versions (comme Git).

Sommaire

• Configurer Visual Studio Code
• L'agent IA est un perpétuel nouveau venu
• Documenter le projet
• Surveiller la consommation des requêtes premium
• « Vibe coder » une fonctionnalité
• Conseils & réflexions

Configurer Visual Studio Code

Votre VS Code et les plugins de Copilot doivent être à jour. Dans les préférences utilisateur, utilisez la configuration suivante :

  "chat.agent.enabled": true,
  "chat.agent.maxRequests": 1000,
  "chat.tools.autoApprove": true,

Attention : cela fait passer l'agent IA de VS Code dans un mode « YOLO » efficace, mais aussi risqué. Vous devrez désormais le surveiller durant son travail et systématiquement utiliser votre système de gestion de versions afin de pouvoir revenir à une version antérieure en cas de problème.

Si ce n'est pas déjà fait, ouvrez la barre latérale de chat en cliquant sur son icône en haut à droite du champ de recherche. En bas de cette barre latérale, passez en mode Agent et choisissez le modèle Claude Sonnet 4.

L'agent IA est un perpétuel nouveau venu

Un agent de programmation IA doit être traité comme un nouveau venu. À chaque nouvelle session de travail, il redécouvre en effet le projet depuis zéro. Et une session de travail ne dure que quelques minutes ou dizaines de minutes, alors on se lasse de se répéter. La bonne nouvelle est qu'il est dévoué et motivé : il fera à chaque fois l'effort de lire les guides d'utilisation que nous lui fournirons. Tout commence donc par un effort de documentation.

Documenter le projet

Dans cette section, nous allons mettre en place un embryon de documentation à l'intérieur de votre projet. Voici la structure visée :

_docs/
├── Code Style Guidelines.md
├── How to Write a TIP.md
├── Onboarding.md
└── Refactoring & Programming Principles.md
_plans/
.github/
└── copilot-instructions.md
CLAUDE.md

Assurez-vous que votre projet est sauvegardé dans le système de gestion de versions et que l'état du répertoire de travail est propre.

À partir d'ici, nous « vibe coderons » ce que nous pourrons. Parce que, eh !, c'est l'esprit ! Donnez ce prompt à votre agent :

Create two directories `_docs` and `_plans` at the root of the repository. If a `.gitignore` file exists, add `_plans` to it.

Le fichier Onboarding.md

Le premier jet du guide d'intégration (« onboarding guide ») de votre projet sera généré grâce à une commande fournie par VS Code :

1. Dans VS Code, appuyez sur Ctrl+Shift+P (ou Cmd+Shift+P sur Mac) et recherchez « Chat: Generate Workspace Instructions File ». Cette commande vous fournit un prompt qui génèrera un nouveau fichier .github/copilot-instructions.md.
2. … Mais nous allons déplacer le contenu de ce fichier. Voici le prompt :

Empty the `.github/copilot-instructions.md` file, move its content into a new file `_docs/Onboarding.md`. Leave the `copilot-instructions.md` file empty. Also, change the title to `# Onboarding Guide`.

Le fichier Code Style Guidelines.md

Il nous faut des conventions de codage. Envoyez la sauce :

You are tasked to write a new file `_docs/Code Style Guidelines.md` that will contain the code style rules of this repository. If there is any information about code style in `_docs/Onboarding.md`, extract it. Also explore the codebase to deduce existing code style rules. Do not invent any rule that is not observed in the codebase. The rules must be short, in the form of bullet list(s).

Le fichier Refactoring & Programming Principles.md

Vous aurez l'occasion de le découvrir : les agents de programmation sont têtus pour certaines choses, comme les commentaires qui répètent inutilement le code. Ils préfèrent aussi paresseusement dupliquer et complexifier le code plutôt que de refactoriser, quand bien même ils en seraient parfaitement capables ! C'est pourquoi nous avons besoin d'un document pour inciter à la refactorisation. Nous commencerons par le faire générer, mais vous aurez bien entendu l'occasion de le réécrire dans le but de limiter les défauts de l'agent qui vous embêteront le plus. Surfons sur la vibe avec :

Write a new file `_docs/Refactoring & Programming Principles.md`. This will be a prompt that an AI agent will read when it is asked to refactor. It should contain the principles of refactoring and programming, such as SRP (Single Responsibility Principle), DRY (Don't Repeat Yourself), and YAGNI (You Aren't Gonna Need It). Be concise and clear. Do not use bullets on this one. Just a title level 2 and a short paragraph for each principle should be fine. The SRP principle is the most important, emphasis it and explain that big functions with inline comments should be rewritten into small well-named functions.

Le fichier How to Write a TIP.md

Nous allons récupérer ce document-ci depuis un projet open-source qui occupe mon temps libre. Il s'agit d'une procédure qui détaille comment rédiger un plan d'implémentation approfondi que l'on désignera par « TIP ». Même si on veut reprendre le fichier tel quel, ce n'est pas une raison pour le faire nous-même :

Create a new file `_docs/How to Write a TIP.md`. Fetch its content from here: https://gitlab.com/paroi/opensource/paroicms/-/raw/main/_docs/How%20to%20Write%20a%20TIP.md

Une remarque : j'utilise l'acronyme « TIP » pour « Thorough Implementation Plan », afin de distinguer ce type de plan d'implémentation particulier. En effet, l'agent IA a également ses propres règles de rédaction de plans d'implémentation, il faut pouvoir faire la différence.

Le fichier CLAUDE.md

Désolé, je vais vous mettre à contribution sur celui-là. Créez un fichier CLAUDE.md (attention à la casse), à la racine de votre dépôt, avec le contenu suivant (remplacez « YourProjectName » par le nom de votre projet) :

# YourProjectName Development Instructions

Always read `_docs/Onboarding.md` before anything else. Then, you MUST select the relevant internal documentation files and read them ENTIRELY.

## Internal documentation

Most frequently consulted procedures:

- `_docs/Code Style Guidelines.md` - ALWAYS READ BEFORE CODING

Additional procedures (read as needed):

- `_docs/How to Write a TIP.md` - A TIP (for _Thorough Implementation Plan_) is a special kind of implementation plan

Architecture and design documents:

- `_docs/Refactoring & Programming Principles.md` - How to apply SRP, DRY, YAGNI

Au fur et à mesure que vous apprendrez à travailler avec l'agent IA, vous rédigerez ou ferez rédiger des documentations pour un nombre croissant de procédures, sous la forme de documents « How to XXX.md ». Ensuite, référencez ces fichiers ici dans le fichier CLAUDE.md en ajoutant des entrées dans la liste des procédures.

Pourquoi ce fichier CLAUDE.md ? C'est le fichier de documentation de Claude Code. L'agent IA d'Anthropic a été un précurseur, il est toujours le grand champion de sa catégorie. Alors honneur aux anciens ! Dans ce tutoriel, j'ai voulu montrer comment rendre disponible une même documentation pour plusieurs agents IA. Et je propose le fichier CLAUDE.md comme point d'entrée commun de la documentation des agents IA.

Le fichier copilot-instructions.md

Dans le fichier .github/copilot-instructions.md, laissez un simple message :

[Read these instructions](../CLAUDE.md)

---
alwaysApply: true
---

ALWAYS read the instructions in `CLAUDE.md` ENTIRELY.

Surveiller la consommation des requêtes premium

Nous utilisons Claude Sonnet 4 qui est un modèle premium. Aussi, il faut commencer à surveiller le niveau de consommation des requêtes premium car il y a une limite mensuelle. Cliquez sur l'icône du chat située en bas dans la barre latérale. Repérez le pourcentage de requêtes premium restantes pour le mois en cours.

Astuce : même s'il ne s'agit pas de vibe coding à proprement parler, n'hésitez pas à débloquer toute l'assistance à la programmation en cochant les cases de ce dialogue.

« Vibe coder » une fonctionnalité

Implémenter une fonctionnalité, cela commence par la rédaction de spécifications. Lorsque cela est fait, n'oublions pas qu'un agent de programmation IA est, à chaque nouvelle session, un nouveau venu. Même après qu'il ait lu la documentation, on ne lâche pas un nouveau venu sur une base de code existante en lui disant de faire comme il le sent. On lui demande comment il envisage de traiter le problème (c'est le plan d'implémentation), on en discute avec lui. Ensuite on le laisse travailler. À la fin, on vérifie le travail.

Les étapes sont alors les suivantes :

1. Écrire des spécifications techniques ;
2. Faire générer un plan d'implémentation ;
3. Relire le plan et demander à l'agent de le corriger si nécessaire ;
4. Faire appliquer le plan ;
5. Revue de code et demandes de corrections à l'agent IA.

1. Écrire des spécifications techniques

Cette première étape est essentielle et, si elle est bien faite, alors elle est celle qui demande le plus de temps et d'effort de votre part. Rédiger un bon prompt prend de quelques minutes à plusieurs heures. Afin d'historiser les décisions, le bon endroit pour rédiger est d'ordinaire un logiciel de gestion de tickets.

Détaillez comme vous le feriez s'il s'agissait de donner des indications à un développeur sans expérience sur le projet (mais ayant lu la documentation). Ces sections se retrouvent souvent dans mes prompts :

• Une description du comportement qui est implémenté actuellement ;
• La description du comportement attendu après la modification ;
• Les parties du code à lire et à modifier, avec des chemins vers des fichiers sources ou bien une chaîne de caractères de recherche ou une autre manière de les trouver.

Si des consignes identiques doivent être mentionnées systématiquement, amendez les conventions de codage (Code Style Guidelines.md) ou le fichier How to Write a TIP.md plutôt que de les répéter à chaque nouvelle spécification.

Vous trouverez des exemples de prompts de spécifications techniques dans ces tickets.

2. Faire générer un plan d'implémentation

Ici, il faut prendre conscience de l'importance de la « zone de contexte ». Vous ne souhaitez pas que l'agent IA mélange les informations de votre prompt avec celles qu'il a déjà lues sur les tâches précédentes. Vous devez donc repartir d'une session neuve, en cliquant sur le bouton « ＋ » (Nouveau chat).

Initialisez un nouveau chat (« ＋ ») puis écrivez simplement :

Write a TIP. Here are the specs:


[collez vos spec. ici]

Cela aura pour effet de générer un plan d'implémentation dans le dossier _plans.

3. Relire le plan d'implémentation

Relisez attentivement le plan d'implémentation. Discutez des solutions techniques possibles avec votre agent, demandez-lui de le corriger ou de le compléter si nécessaire. En dernier recours, vous corrigerez le plan vous-même à la main, ça arrive.

Je demande parfois de l'aide à un autre agent, et notamment Claude Code, pour m'aider à relire et compléter un plan. Mais plus un plan est complexe et plus il importe de faire l'effort de le comprendre. Sous peine de passer ensuite plus de temps à (faire) corriger qu'à implémenter vous-même. N'espérez jamais qu'un problème complexe puisse se résoudre comme par magie sans que vous n'ayez à comprendre comment !

4. Faire appliquer le plan

Pensez toujours à enregistrer dans le système de contrôle de version (git commit) tous vos éventuels changements en cours avant de demander à l'agent IA d'appliquer un plan d'implémentation. Cela permet de revenir en arrière en cas de problème. Cela permettra aussi de regarder le diff entre le code avant et après l'application du plan.

Initialisez un nouveau chat (« ＋ »), glissez-déplacez le fichier du plan d'implémentation dans le chat, ou bien ouvrez-le et assurez-vous que le fichier ouvert est bien visible par l'agent, puis écrivez :

Apply this implementation plan

Le cas échéant, n'hésitez pas à interrompre l'agent dès que vous vous apercevez qu'il va dans une mauvaise direction. Expliquez-lui ce qui ne va pas, il continuera sa session en prenant en compte votre message.

Avant d'exécuter un plan, relancez toujours une nouvelle session de l'agent. D'abord pour éviter la contamination des informations entre tâches, car cela vous empêcherait d'obtenir un résultat cohérent si vous deviez relancer un plan amendé après un échec. Ensuite parce que l'agent IA devient parfois moins fiable et plus confus lorsque sa fenêtre de contexte se remplit. De plus, en fin de contexte, l'agent se résume automatiquement la situation à lui-même puis relance une session neuve en lui passant le résumé, ce qui augmente l'incertitude sur le résultat ; mieux vaut éviter d'atteindre trop vite cette limite.

Une astuce : le travail de l'agent IA sur votre base de code peut parfois être bloquant puisque votre projet est en train d'être édité et ne compile ou ne s'exécute plus. Si vous vous demandez quoi faire pendant que l'agent fait son travail, mettez ce temps à profit pour rédiger les spécifications techniques des prochaines fonctionnalités. Toutefois, gardez un œil sur ce que fait votre agent.

5. Revue de code et demandes de corrections à l'agent IA

Il arrive que la fonctionnalité implémentée marche du premier coup, et c'est fun ! Mais sur le plan de la qualité du code, ne laissez rien passer. N'acceptez pas du code qui serait moins bon que ce que vous auriez écrit vous-même. Ne faites pas non plus l'impasse sur du code que vous ne comprenez pas : au besoin, si vous vous êtes aventuré loin de votre zone de confort, c'est éventuellement le moment d'apprendre. Quoi qu'il en soit, vous restez responsable du code que vous commitez de la même manière que le conducteur doit garder le contrôle de son véhicule : en cas d'accident, le comportement de la voiture n'est pas une bonne excuse, celui qui utilise l'outil est toujours responsable.

Lorsque vous demandez à l'agent IA de corriger des choses, vous pouvez ensuite lui faire amender la documentation du projet avec ce qu'il a appris. Par exemple :

Update the Code Style Guidelines file with what you've learned.

Il faut parfois terminer le travail à l'ancienne, c'est-à-dire à la main. Sur les tickets difficiles, dans une base de code complexe, l'agent passe à côté de beaucoup de choses. Avec l'expérience vous pourrez anticiper la situation mais non l'éviter. L'agent peut toutefois dégrossir le travail. Et surtout, au fil des mises à jour, sa performance s'améliore à pas de géant.

Conseils & réflexions

Ce que vous risquez si vous ne surveillez pas l'agent IA pendant son travail ?

• Rappelez-vous que dans l'étape de configuration, nous avons désactivé les protections, donc l'agent pourrait lancer des outils dangereux en ligne de commande ;
• Il peut aussi se retrouver bloqué dans une boucle infinie en cherchant une solution à un problème sans la trouver, et consommer ainsi une large part, voire la totalité de vos requêtes premium.

Faites attention aux prompts malintentionnés. Ne lancez pas aveuglément votre agent sur un projet inconnu. Et soyez vigilant à chaque fois que vous lui demandez de rechercher des informations sur Internet.

Le système de gestion de versions est une garantie de sécurité, mais gardez à l'esprit que votre agent sait aussi l'utiliser.

La fenêtre de contexte d'un agent IA est limitée. Nous avons donc intérêt à minimiser la quantité de contexte injectée automatiquement. C'est-à-dire que le temps que vous passerez à rendre plus synthétiques les instructions les plus lues (CLAUDE.md, Onboarding.md) ne sera pas du temps perdu : il faut être à la fois concis et complet. Pour la même raison, mieux vaut séparer les documentations spécifiques dans des fichiers différents en demandant à l'agent de n'ouvrir que ce dont il a besoin.

Évitez ou limitez les ordres désagréables en majuscules dans la documentation. Gageons que les techniques pour forcer une IA à obéir seront de moins en moins pertinentes au fur et à mesure que les modèles de langage s'amélioreront. Votre documentation est là pour durer. Considérez que le contenu du dossier de documentation sera utile à tous les nouveaux-venus sur le projet, IA comme humains. Expliquez donc les choses normalement.

Il sera facile de garder la documentation à jour, vous demanderez à l'agent IA de le faire pour vous.

Le choix de nommer les répertoires _docs et _plans, ou encore l'acronyme « TIP », n'est pas une convention reconnue. Ce sont simplement le résultat de mon expérience et mes choix d'organisation. Il n'existe pas encore de bonnes pratiques en la matière. Je vous ai donné les miennes, adaptez librement.

Si vous vous demandez pourquoi j'insiste sur Claude Sonnet 4, essayez avec un modèle moins premium et vous aurez vite la réponse.

Pour ma part, j'écris mes prompts et la documentation, tout comme le code, en anglais. Mais le français marchera très bien également.

En guise de conclusion, je souhaite ouvrir sur le TDD, dont la version vibe coding est voisine du plan d'implémentation. C'est très efficace pour implémenter un algorithme dans une fonction. Les tests unitaires remplacent alors le plan d'implémentation. Le processus est similaire : 1. Écrire des spécifications. 2. Faire générer des tests unitaires, en précisant à l'agent de ne pas tenter de les exécuter. 3. Vérifier les tests, les faire compléter et modifier. 4. Faire générer une implémentation à partir des spécifications, l'agent doit faire en sorte que les tests passent. 5. Revue de code et demandes de refactorisations car l'agent, en luttant pour faire passer certains tests, aura peut-être dupliqué des parties de code.

Happy Vibe Coding!

Retrouvez l'intégralité de ce tutoriel en ligne sur Alsacreations.com

Flux (rss): http://www.alsacreations.com/rss/actualites.xml