La fonctionnalité
Le Mail MVP de sh0 transforme une seule commande CLI en une plateforme d'hébergement mail complète. Stalwart Mail Server, génération de clés DKIM, vérification DNS, configuration automatique Cloudflare, gestion des boîtes aux lettres et des alias -- le tout enveloppé dans un dashboard à 4 onglets avec support i18n en 5 langues.
L'implémentation s'étend sur ~5 000 lignes réparties dans 30 fichiers : une migration SQL, 3 modèles Rust, la crypto DKIM, un gestionnaire de conteneur Docker, un client API REST Stalwart, la vérification DNS via dig, des extensions DNS Cloudflare, 15 handlers API avec RBAC et un dashboard Svelte 5 avec un assistant de configuration, une page de détails et des modales CRUD complètes.
Le problème du code généré par l'IA
Chaque session d'IA optimise localement. La session 1 construit la couche base de données. La session 2 construit l'API. La session 3 construit le dashboard. Chaque session produit du code fonctionnel -- mais est-ce que l'interface TypeScript du dashboard correspond à la struct de réponse Rust ? Est-ce que la chaîne de format d'enregistrement DNS dans mail_crypto.rs correspond à ce que l'assistant de configuration affiche ? Est-ce que l'enum DnsStatus se sérialise en "pass" ou "Pass" ?
La cohérence inter-couches est l'endroit où se cachent les bugs. Les pièces individuelles fonctionnent bien de manière isolée ; c'est l'intégration qui casse.
La méthodologie
Nous utilisons un pipeline construire-auditer-auditer-approuver :
- Sessions de build (3 sessions) : chacune focalisée sur une couche. Infrastructure, API, Dashboard.
- Audits focalisés (2 tours) : chaque session d'audit examine une session de build. L'audit de la session 2 a trouvé 4 problèmes importants (timeouts dig, nettoyage des conteneurs Docker orphelins, journalisation des échecs partiels Cloudflare, adresses d'alias optionnelles). L'audit de la session 3 a trouvé 3 problèmes importants (chaînes anglaises codées en dur, mauvaises clés i18n pour les états vides, texte de statut non traduit).
- Audit global (cette session) : un contexte frais lit chaque fichier et vérifie le système dans son ensemble.
Ce que l'audit global a trouvé
Nous avons défini 230 éléments de checklist répartis dans 19 sections :
- Correction du schéma : 11 vérifications (types de colonnes, contraintes, index, clés étrangères)
- Couche modèle : 13 vérifications (mappages from_row, méthodes CRUD, annotations serde)
- Crypto : 10 vérifications (génération de clés DKIM, chaînes de format DNS, gestion d'erreurs)
- Docker : 14 vérifications (image, ports, volumes, labels, idempotence, nettoyage)
- Client Stalwart : 11 vérifications (auth, endpoints, gestion d'erreurs, timeouts)
- Vérification DNS : 12 vérifications (6 types d'enregistrements, prévention d'injection, timeouts)
- Cloudflare : 9 vérifications (création MX/TXT, gestion d'échecs partiels, TTL)
- Handlers API : 30 vérifications (15 endpoints, RBAC, chiffrement, validation, journalisation d'audit)
- Routeur et OpenAPI : 6 vérifications
- Types requête/réponse : 8 vérifications
- Types TypeScript et client API : 9 vérifications (correspondance champ par champ)
- Pages dashboard : 51 vérifications (liste, assistant, détails avec 4 onglets)
- i18n et accents français : 14 vérifications (les accents sont critiques -- c'est une plateforme éducative)
- Sécurité : 12 vérifications (chiffrement, injection, XSS, secrets dans les réponses)
- Cohérence inter-couches : 9 vérifications (BD == Modèle == API == TypeScript == Dashboard)
- Vérification des correctifs précédents : 7 vérifications (les 7 correctifs des audits précédents toujours en place)
- Vérification de build : 4 vérifications
Résultats : 227 réussis, 3 échoués. 0 critique. 2 importants (les deux corrigés dans la session).
Les deux problèmes importants étaient des problèmes d'i18n : des chaînes anglaises codées en dur qui contournaient le système de traduction, et une colonne created_at manquante dans la table des boîtes aux lettres. Les deux ont été corrigés en ajoutant 20 nouvelles clés i18n dans les fichiers de 5 langues et en mettant à jour 3 composants Svelte.
Pourquoi ça fonctionne
L'idée clé est des perspectives diverses à la bonne granularité :
- Les sessions de build optimisent pour la correction au sein de leur couche
- Les audits focalisés détectent les bugs au sein de cette couche depuis une perspective fraîche
- L'audit global détecte les incohérences inter-couches qu'aucun audit mono-couche ne peut voir
L'audit global a trouvé des problèmes que les deux audits focalisés avaient manqués -- de l'anglais codé en dur dans des fallbacks d'erreur, la colonne de table manquante. Ce sont le genre de bugs qui passent à travers quand chaque relecteur ne voit que sa propre tranche.
Les chiffres
| Métrique | Valeur |
|---|---|
| Lignes de code totales | ~5 000 |
| Fichiers touchés | 30 |
| Sessions de build | 3 |
| Tours d'audit | 3 (2 focalisés + 1 global) |
| Problèmes totaux tous audits confondus | 10 |
| Problèmes critiques | 0 |
| Problèmes importants corrigés | 9 |
| Problèmes mineurs | 4 |
| Éléments de checklist vérifiés | 230 |
| Langues avec accents corrects | 5 |
Le coût du pipeline d'audit est ~30 minutes de calcul IA. Le coût de livrer une fonctionnalité d'hébergement mail avec une fuite de clé DKIM, une injection de commande dans dig, ou "Boites aux lettres" sans l'accent circonflexe sur une plateforme éducative ? Bien plus élevé.