Ces derniers mois, entre les clients, les congés et les virus que les enfants ramènent de l'école, la gestion du temps pro était… compliquée. Je me suis retrouvé à bloquer des collègues sur des sujets où, franchement, mes réponses sont assez prévisibles.
Est-ce que cette PR respecte les Conventional Commits ? Est-ce que cette doc devrait être en AsciiDoc plutôt qu'en Markdown ? Est-ce que tu as essayé Townscaper ?
Oui. Oui. Et oui, vraiment, essayez Townscaper.
Ce constat m'a fait réfléchir : et si je pouvais me dupliquer pour ne bloquer personne sur ces points-là ? Et comme mon site rickroll wraas.click fêtait ses 6 ans, l'occasion était trop belle. J'ai gardé le nom, gardé l'esprit, et j'ai construit un "vrai" produit par-dessus : WRAAS (Weighted Romain Algorithmic Approximation Software), un CLI jumeau numérique qui simule mes réponses techniques.
Le résultat est une blague. Mais le produit, lui, est construit sérieusement.
Et c'est ça le sujet de cet article : comment appliquer des standards professionnels à un projet dont le seul but est de faire rire le 1er avril ?
Le concept en bref
WRAAS est un CLI qui reproduit mes réponses, mes réflexes et mes opinions. Pas avec du machine learning ou un LLM fine-tuné sur mes messages Slack, mais avec des règles codées en dur, parce que mes avis sont suffisamment prévisibles pour ça.
Vous lui posez une question, il évalue toutes les options (y compris les mauvaises), documente pourquoi chacune a été rejetée, et répond en 113 millisecondes. Avec un soupir calibré. Le soupir est loggé dans ~/.wraas/sigh.log, évidemment.
Chaque feature du produit parodie une de mes marottes de développeur. Et chacune de ces marottes a été appliquée sérieusement pendant la construction du projet. C'est ce miroir entre le produit et sa fabrication qui fait, je crois, l'intérêt du truc.
Conventional Commits : dans le produit et dans le process
Dans le produit, WRAAS intègre un module de Conventional Commit Enforcement. Il analyse vos messages de commit et rejette ceux qui ne respectent pas la spécification. Un commit "fix stuff" déclenche une "quiet devastation". Un "wip" pousse le Sigh Calibration System au niveau EXISTENTIAL, le plus élevé des 5 niveaux.
Dans la construction, chacun des 30+ commits du projet suit scrupuleusement le format <type>(<scope>): <description>. Les types utilisés (feat, fix, refactor, docs, style, ci) reflètent la nature exacte de chaque changement. Le scope distingue site et cli. Le tout alimente semantic-release pour le versioning automatique.
Un projet qui se moque des mauvais commits ne peut pas se permettre d'en avoir.
CI/CD & GitHub Actions : automatiser l'automatiseur
Dans le produit, le GitHub Actions Encouragement Module détecte les scripts shell qui pourraient être remplacés par des GitHub Actions. Il vous le suggère poliment. Très poliment.
Dans la construction, le projet utilise quatre workflows GitHub Actions : déploiement du site, build Go avec tests unitaires et end-to-end, versioning automatique via semantic-release, et builds multi-plateformes via goreleaser. Deux d'entre eux sont des reusable workflows chaînés.
Le détail qui compte : chaque Action est épinglée par commit SHA complet avec le tag en commentaire (actions/checkout@de0fac2... # v6.0.2). C'est une bonne pratique de sécurité supply-chain rarement appliquée, même sur des projets "sérieux". Ajoutez Dependabot pour les mises à jour de dépendances, et vous avez une CI/CD plus rigoureuse que beaucoup de projets en production.
Documentation & Diataxis : documenter la blague
Dans le produit, l'Antora/AsciiDoc Compliance Engine détecte du Markdown dans un repo de documentation et le flagge. Parce que la documentation mérite mieux que du Markdown (oui, c'est une de mes marottes, et WRAAS a même une page d'explication dédiée : "Why Not Markdown?").
Dans la construction, la documentation du projet suit le framework Diataxis à la lettre :
- Tutorials : Getting Started, Your First Query, Configuring Sigh Thresholds
- How-To Guides : Decision Requests, GitHub Actions Integration, Commit Enforcement
- Reference : CLI, Configuration, les 17 entrées de la Decision Matrix (DME)
- Explanation : Why Bad Options Matter, Full Commitment Philosophy
Chaque DME est numérotée, documentée et versionnée. Et les numéros ne sont pas arbitraires : DME-0042 (la réponse à tout), DME-0404 (quality not found), DME-0418 (I'm a teapot), DME-1337 (l33tspeak), DME-2001 (l'odyssée)… Les codes d'erreur célèbres deviennent des entrées de rejet documentées. Les admonitions (note, tip, warning, important, caution) sont stylisées. La table des matières suit la position du scroll.
On pourrait se dire que documenter un produit parodique est excessif. Mais la documentation fait partie de la blague : elle est drôle parce qu'elle est sérieuse.
Automatisme & DX : tout à une commande
WRAAS automatise mes réponses pour qu'elles soient disponibles sans moi. L'ironie serait de devoir bricoler manuellement pour le faire tourner. Un justfile centralise toutes les recettes de développement :
just serve: site en live reload avec browser-syncjust validate: validation HTML (attributlang,altsur les images)just build: compilation du CLI Gojust test-cli+just test-e2e: tests unitaires et end-to-endjust stats: comptage de lignes par type de fichier
Zéro étape manuelle. Un contributeur clone le repo, tape just, et voit tout ce qu'il peut faire. C'est une habitude que j'applique sur tous mes projets, et un side project du 1er avril ne fait pas exception.
Accessibilité : tout le monde mérite la même blague
L'accessibilité n'est pas une marotte personnelle. C'est un standard. Mais le réflexe courant sur un projet "fun" serait de s'en passer : "c'est juste une blague, pas besoin de se prendre la tête."
Je ne suis pas d'accord. Si le produit est destiné à faire rire, alors tout le monde devrait pouvoir en profiter.
Concrètement, le site WRAAS intègre :
- Un skip link pour sauter directement au contenu
- Des attributs ARIA sur la navigation, les modales et les boutons (
aria-label,aria-expanded,aria-controls,aria-modal) - Un focus trap dans la modale de demande d'accès (la touche Tab boucle correctement, Escape ferme la modale, le focus est restauré à la fermeture)
- Le respect de
prefers-reduced-motionpour désactiver les animations - Du HTML sémantique :
<nav>,<main>,<section>,<article>, avec des headings ordonnés
Si même un site de poisson d'avril peut appliquer ces standards, n'importe quel projet le peut.
Parodie du hype, réflexion sincère
WRAAS est une blague. Mais derrière la parodie, il y a une question que je trouve sincèrement intéressante : qu'est-ce qu'on peut réellement automatiser chez un développeur ?
On vit une époque où les jumeaux numériques et les agents IA sont présentés comme la solution à tout. Des outils qui vont "penser comme vous", "coder comme vous", "décider comme vous". WRAAS pousse cette logique jusqu'à l'absurde : un logiciel qui reproduit mes soupirs, mes opinions sur les Conventional Commits et mon obsession pour Townscaper.
Et pourtant, en construisant ce projet, je me suis rendu compte que certaines de mes réponses sont effectivement automatisables. Les code reviews sur le format des commits, les recommandations de stack documentation, les vérifications de conformité : ce sont des règles, pas de l'intuition.
Ce qui ne peut pas l'être, c'est le contexte. Savoir quand soupirer. Comprendre pourquoi quelqu'un a écrit "wip" à 3h du matin. Décider de laisser passer un commit imparfait parce que la personne en face a besoin d'encouragement, pas d'une règle.
Un jumeau numérique peut reproduire les réponses. Il ne peut pas reproduire le jugement.
Essayez-le
WRAAS est disponible sur wraas.click/digital-twin-product. Le code source est ouvert, la documentation est complète, et le taux de désertion est de 0.00%. Pour demander l'accès au CLI, rendez-vous en bas de la landing page.
Bon 1er avril.
