Quality Engineering
Déplacer la qualité vers la gauche, et l’observer à droite.
01 — Le problème
La qualité est encore une phase, située juste avant la mise en production, et portée par une équipe distincte. Les défauts sont donc trouvés au moment où ils coûtent le plus cher à corriger. À l'inverse, une fois en production, plus personne ne mesure la qualité perçue : vous découvrez les problèmes par les tickets de support.
02 — Ce que nous faisons
- 01
Rendre le produit testable
Identifiants stables dans l’interface, points d’injection de données, horloge pilotable, dépendances externes simulables. Sans testabilité, tout le reste coûte trois fois plus.
- 02
Déplacer les contrôles vers le poste de développement
Types, lint, tests unitaires et vérifications avant commit. Un défaut trouvé dans l’éditeur coûte quelques secondes ; le même en recette coûte des jours.
- 03
Installer le continuous testing
Des contrôles à chaque étape de la chaîne, avec un temps de retour compatible avec le rythme de livraison.
- 04
Observer la qualité en production
Taux d’erreur, latence perçue, parcours abandonnés. Le shift-right n’est pas un gadget : c’est la seule mesure de la qualité réellement livrée.
- 05
Définir des métriques qui pilotent une décision
Chaque indicateur suivi doit être relié à une action possible. Les autres sont du bruit.
04 — Ce que vous recevez
Des livrables nommés, pas des promesses. Vous savez ce que vous recevez avant de commencer.
Plan de testabilité produit
Chaîne de contrôles du poste au run
Socle d’observabilité de la qualité
Jeu d’indicateurs relié aux décisions
05 — Écosystème technique
Les outils ne font pas la qualité. Nous les maîtrisons pour pouvoir choisir le bon, pas pour en faire un argument.
- GitHub Actions
- GitLab CI
- Jenkins
- SonarQube
- OpenTelemetry
- Grafana
- Prometheus
- Docker
- Kubernetes
