Construire la confiance
Indicateurs de qualité
Soyons honnêtes : c'est un petit site portfolio. Il n'y a pas grand-chose dessus. Obtenir de bons scores Lighthouse ici n'est pas vraiment un exploit, et je ne montre pas ces chiffres pour frimer.
En dehors du métier, la plupart des gens associent encore l'IA à du contenu bâclé. Mais les développeurs savent déjà que l'IA peut aider à produire du code propre, rapide et accessible. Cette page vise à illustrer ça. Chaque déploiement passe par Lighthouse, et le pipeline CI bloque tout ce qui est en dessous des seuils. Ces scores sont ceux qui ont été déployés.
Ci-dessous vous trouverez les scores PageSpeed Insight, la couverture de tests, les vérifications d'accessibilité, la taille du bundle, et les contrôles qualité qui protègent chaque déploiement. Tout est généré automatiquement — rien n'est trié ou sélectionné à la main.
Contrôles qualité
Ces scores proviennent de contrôles qualité automatisés qui s'exécutent à chaque commit, pas de vérifications ponctuelles avant une mise en production. Les outils utilisés sont tous librement disponibles, et le choix de les appliquer est une décision d'ingénierie.
- TypeScript en mode strictpassing
- ESLint appliquépassing
- Formatage Prettierpassing
- Commits conventionnelspassing
- CI ·Couverture des tests ≥ 80 %passing
- CI ·Tests E2E validéspassing
- CI ·Seuils Lighthouse CIpassing
Couverture de tests
Les tests unitaires et de bout en bout s'exécutent à chaque push, avec des seuils de couverture appliqués en CI. La suite de tests unitaires couvre le rendu des composants, la logique des données et les actions serveur, tandis que les tests E2E vérifient la navigation complète, les interactions de formulaires et l'accessibilité via un vrai navigateur. Si la couverture passe en dessous des minimums configurés, le build échoue.
Scores PageSpeed Insight
Dernier audit : 2 avril 2026
Les sites lents perdent des utilisateurs, et cette corrélation a été suffisamment mesurée pour ne pas avoir besoin d'être répétée ici. Ce site reste rapide grâce à des ressources optimisées, un minimum de JavaScript côté client, des formats d'image modernes et une diffusion en périphérie.
Le score d'accessibilité mesure si les personnes ayant différentes capacités peuvent réellement utiliser le site. Cela implique du HTML sémantique, une hiérarchie de titres correcte, un contraste de couleurs suffisant, une navigation au clavier et des attributs ARIA là où ils sont nécessaires.
Cette catégorie couvre l'hygiène technique : HTTPS partout, pas d'API dépréciées, des en-têtes sécurisés, une console propre et une gestion correcte des ressources. Ce sont les détails que les utilisateurs ne remarquent jamais quand c'est bien fait, mais qu'ils perçoivent immédiatement quand ça ne l'est pas.
Un bon SEO découle naturellement d'un code bien structuré. Le balisage sémantique, les balises meta appropriées, les données structurées, un sitemap valide et des temps de chargement rapides couvrent déjà la plupart de ce que les moteurs de recherche recherchent.
Conformité accessibilité
Le score d'accessibilité Lighthouse détecte beaucoup de choses, mais ne couvre pas l'intégralité des WCAG. Ce site vise également la conformité WCAG 2.1 AA, ce qui signifie des indicateurs de focus visibles, des liens d'accès rapide au contenu, le support de la réduction de mouvement et un texte lisible à 200% de zoom. L'outillage automatisé gère les vérifications programmatiques, et les tests manuels comblent les lacunes que l'outillage ne peut pas atteindre.
WCAG 2.1 Niveau AA
8 pages testées
Testé avec axe-core
Taille du bundle
Un bon score Lighthouse ne signifie rien si la charge JavaScript explose au prochain déploiement. La taille du bundle est suivie dans le processus de build, et le site s'appuie sur les composants serveur de Next.js pour garder la majorité de la logique hors du client. Les pages qui n'ont pas besoin d'interactivité ne chargent pas de bundle JS.