trainUs/website/content/blog/2026-07-21-ia_methode.fr.md

---
title: 'IA : la méthode'
date: 2026-07-21
description: "Comment j'ai travaillé avec l'IA pour créer TrainUs : la méthode"
draft: false
---

Dans un [précédent article]({{< relref "2026-06-20-ia_pourquoi.fr.md" >}}), j'expliquais _pourquoi_ j'ai massivement utilisé l'IA pour créer TrainUs. Ici, je vais parler du _comment_.

Parce que oui, suivre une méthode ça aide ! Du coup j'ai adopté peu ou prou la méthode habituelle en fait : une spec, un plan, des règles (bon ça s'est plus explicite avec une IA), des tests (vital ici) et de la doc (pour moi, pour elle, pour les contributeurs et pour les utilisateurs).

## L'architecture

Je vous ai dit que j'étais du genre feignant sur l'architecture, mais soyons honnêtes : les décisions structurantes, c'est moi qui les ai prises, et dès le départ. Une application 100 % locale, sans serveur, et qui fonctionne entièrement hors ligne : les données restent sur l'appareil de l'utilisateur, dans une base embarquée directement dans le navigateur. Pas de compte, pas de cloud, pas de backend à maintenir — et une séance qui ne dépend pas de la qualité du réseau dans la salle de sport.

Là où je délègue, c'est l'architecture de détail : le découpage en composants et composables, la couche d'accès aux données, l'organisation du code. L'IA propose dans un cadre. À la racine du projet, un fichier de règles (`AGENTS.md`) que l'IA lit à chaque session : KISS, SOLID, DRY, changements minimaux plutôt que gros refactoring. Et surtout : un plan étape par étape, validé par moi **avant** d'écrire la moindre ligne de code, et une validation manuelle entre chaque étape (bon là faut que je revois, souvent j'ai peu de chose à redire donc à voir comment "moins" valider). Pas de "vas-y, fais toute l'appli". Une feature à la fois. D'ailleurs je prépare souvent le texte de mes features en amont de mes sessions de travail - en mode offline ;-) .

Certaines règles sont non négociables et écrites noir sur blanc. Exemple : "interdiction d'incrémenter la version du schéma de la base de données sans me demander d'abord" parce que sinon à chaque changement de la DB elle incrémente la version sauf que j'ai jamais fait de release donc ça sert à rien.

Parfois l'IA fait des choix pour que ça marche qui sont malheureux. Exemple: "si le système OPFS ne marche pas créer la base de données en mémoire", ok ça ne plante pas l'application mais il ne faut pas le faire, il faut dire à l'utilisateur que l'application ne marche pas sur son navigateur.

## La stack technique

La stack, soyons précis, c'est un travail d'équipe — mais rien n'y entre sans ma validation, et le mode de décision a varié d'une brique à l'autre. SQLite WASM directement dans le navigateur, avec les données stockées sur OPFS (Origin Private File System) : ça, je l'ai imposé, c'est ce qui rend le 100 % local possible avec une vraie persistance. Vue 3 ? Une co-décision. Vite et i18next ? Des propositions de l'IA que j'ai validées — je voulais du multilingue, elle m'a proposé i18next, adopté. Et pour Hugo côté site, on a fait une étude comparative dans les règles… même si, j'avoue, je l'avais déjà en tête.

En fait il faut décider ce qui est non négociable, ce qui peut être discuté et ce qui est de l'ordre de l'exploratoire (ou sans avis). Et une fois la stack posée et documentée, l'IA sait où elle va (et moi aussi).

## La spec fonctionnelle

Tout part d'une spécification écrite : ce que fait l'appli, les deux modes (édition et exécution), les entités. De là, l'IA a dérivé un plan (`plan.md`) découpé en étapes, chacune avec son statut et sa méthode de vérification. C'est le document de pilotage du projet : je sais ce qui est fait, ce qui attend ma validation, ce qui reste. Et c'est l'IA qui le tient à jour — ça fait partie de sa définition de "terminé".

## Le decision log

Chaque décision technique est consignée dans un journal : la date, la décision, et surtout le _pourquoi_ (ce qui a été envisagé et rejeté). C'est doublement utile avec l'IA. D'une session à l'autre, elle ne se souvient de rien : le log lui redonne le contexte et lui évite de re-proposer une solution déjà écartée. Et pour moi, quand je reviens trois semaines plus tard je peux retourner lire pourquoi on a fait ça. Là encore, c'est l'IA qui rédige à partir de nos échanges.

## Les tests

Mon garde-fou numéro un. Des tests de bout en bout avec Playwright, sur Firefox **et** Chromium, qui couvrent les chemins verts (le flux nominal) et les chemins rouges (mauvaises saisies, cas limites, états d'erreur). Une étape n'est pas terminée tant que les tests ne passent pas sur les deux navigateurs.

C'est ce qui me permet d'assumer de peu relire le code généré : si la suite complète passe, que la nouvelle feature est testée dans les deux sens et que ma validation manuelle est OK, le risque de régression est faible. Sans cette base de tests, travailler comme ça serait de l'inconscience.

## Diataxis pour la doc

La documentation utilisateur suit le cadre [Diataxis](https://diataxis.fr/) : un tutoriel (démarrage rapide), des guides pratiques (comment faire X), une référence (le guide utilisateur écran par écran) et une explication (comprendre les concepts). Le tout en anglais et en français, plus une doc technique séparée pour les développeurs.

Soyons honnêtes : seul, avec mon temps libre, je n'aurais **jamais** écrit tout ça. Avec l'IA, la doc est mise à jour à chaque étape — c'est dans la définition de "terminé", au même titre que les tests. Donner un cadre connu comme Diataxis, ça marche très bien : elle sait exactement quel type de contenu va où, et le résultat est bien plus structuré qu'un "écris-moi de la doc".

## Bref

La méthode, c'est du classique en fait : une spec, un plan, des règles, des tests, de la doc. Rien de révolutionnaire, c'est ce qu'on devrait faire sur n'importe quel projet. La différence, c'est que l'IA rend le coût de cette rigueur quasi nul — et qu'en retour, cette rigueur est exactement ce qui rend l'IA fiable. Le cadre, c'est ce qui transforme un générateur de code en vrai coéquipier. Bon par contre attention elle peut devenir feignante elle aussi par moment et oublier la doc ou les tests ou le decision log donc faut quand même garder les yeux ouverts et le lui rappeler (ça me rappelle certaines personnes :-p ).