Vous connaissez déjà la théorie : la Definition of Done est l'engagement de l'Increment. Ce que vous cherchez maintenant, c'est un modèle prêt à utiliser dans votre prochain Sprint. Cet article vous donne 8 modèles complets, une checklist universelle, des cas concrets et un bloc à copier-coller. Pour la théorie détaillée, gardez le pilier Definition of Done sous la main.
1. Pourquoi utiliser un modèle de Definition of Done ?
Partir d'un modèle éprouvé fait gagner plusieurs Sprints d'itérations. Cela n'exempte pas la Scrum Team d'adapter la DoD à son contexte, mais évite les oublis classiques et pose un socle de qualité dès le Sprint 1. Les bénéfices sont concrets :
- Homogénéité : tous les Developers appliquent la même définition de « fini ».
- Qualité : les critères couvrent tests, sécurité, performance, documentation.
- Transparence : le Product Owner et les parties prenantes savent ce que « Done » signifie.
- Réduction des bugs : les défauts sont détectés dans le Sprint, pas en production.
- Prédictibilité : la vélocité mesurée reflète du travail réellement terminé.
2. 8 modèles de Definition of Done prêts à utiliser
Chaque modèle couvre 8 dimensions : développement, tests, documentation, sécurité, performance, déploiement, validation fonctionnelle et critères spécifiques au contexte. Choisissez celui qui correspond à votre produit, copiez-le, ajustez 2–3 critères et vous avez une DoD opérationnelle.
SPA React/Vue/Angular, site marketing, portail interne.
- Code revu par ≥ 1 pair
- Respect ESLint / Prettier
- Aucun `TODO` sans ticket associé
- Tests unitaires ≥ 80 % de couverture
- Tests d'intégration verts
- 1 test end-to-end sur le parcours critique
- README à jour
- Changelog incrémenté
- Storybook mis à jour si composant UI
- Aucune vulnérabilité critique (npm audit)
- En-têtes CSP validés
- Aucune donnée sensible loggée
- Lighthouse Performance ≥ 85
- Aucun bundle > 250 kB gzipped ajouté sans validation
- Merge sans conflit sur main
- CI verte
- Déployable en un clic
- Product Owner valide la démo
- Critères d'acceptation cochés
- Responsive testé mobile / tablette / desktop
- Accessibilité WCAG 2.1 AA sur les écrans touchés
Microservice backend, API publique ou interne.
- Code revu et approuvé
- Contrat OpenAPI mis à jour
- Versioning respecté
- Tests unitaires ≥ 85 %
- Tests d'intégration sur chaque endpoint
- Tests de contrat (Pact) verts
- Swagger / OpenAPI publié
- Exemples de requêtes / réponses fournis
- Rate limits documentés
- Auth vérifiée sur chaque endpoint
- Validation d'entrée systématique
- Aucun secret en clair
- P95 < 300 ms sur endpoint concerné
- Load test 100 rps validé
- Migration DB rétrocompatible
- Feature flag si breaking change
- Rollback documenté
- Product Owner valide via Postman ou UI cliente
- Codes d'erreur explicites
- Observabilité : logs structurés + métriques + traces
- Idempotence des mutations vérifiée
iOS, Android natif ou React Native / Flutter.
- Code revu
- Aucun warning compilateur ajouté
- Analyse statique (SonarQube) OK
- Tests unitaires ≥ 75 %
- Tests UI sur 3 tailles d'écran
- 1 test end-to-end sur parcours critique
- Notes de version rédigées
- Documentation composants partagés à jour
- Aucune clé API dans le bundle
- Chiffrement des données locales sensibles
- Certificate pinning si HTTPS critique
- Démarrage à froid < 2 s
- Aucune fuite mémoire détectée
- Taille APK/IPA impact < 500 kB
- Build signé
- Publiable TestFlight / Play Console interne
- Product Owner valide sur device physique
- Parcours offline testé
- Compatibilité iOS N-2 et Android N-3
- Accessibilité VoiceOver / TalkBack sur écrans clés
Plateforme multi-tenant B2B, facturation par abonnement.
- Code revu par ≥ 2 pairs si zone critique
- Migration DB testée en staging
- Feature flag posé
- Tests unitaires ≥ 85 %
- Tests d'intégration multi-tenant
- Tests de non-régression sur les 3 rôles principaux
- Aide en ligne mise à jour
- Notes de release client rédigées
- Base de connaissance support à jour
- Isolation tenant garantie et testée
- RGPD respecté (logs, exports, suppression)
- Audit trail activé
- Aucune requête > 500 ms sur écran principal
- Queries N+1 vérifiées
- Blue-green ou canary configuré
- Rollback < 5 min
- Alerting Grafana / Datadog en place
- Product Owner + Customer Success valident
- Analytics produit instrumenté
- Facturation impactée validée par l'équipe finance
- Compatibilité SSO clients existants vérifiée
Pipelines ETL, entrepôt de données, dashboards analytiques.
- Code SQL / dbt revu
- Naming conventions respectées
- Lineage documenté
- Tests de fraîcheur des données
- Tests d'unicité / not-null / valeurs attendues
- Tests de non-régression sur métriques clés
- Documentation dbt / catalog générée
- Dictionnaire de données à jour
- Accès par rôle vérifié
- Aucune PII exposée sans anonymisation
- Chiffrement au repos activé
- Pipeline < SLA défini
- Coût cloud estimé validé
- Déployé via CI/CD, pas en manuel
- Rollback de schéma testé
- Business Owner valide le dashboard
- Chiffres réconciliés avec source de vérité
- Historisation prévue (SCD2 si besoin)
- Alerting anomalies configuré
Modèles prédictifs, moteurs de recommandation, LLM applicatifs.
- Code revu
- Notebooks convertis en scripts reproductibles
- Seed fixée pour la reproductibilité
- Tests unitaires sur features engineering
- Évaluation offline sur dataset de référence
- A/B test ou shadow mode planifié
- Model card rédigée
- Dataset card documentée
- Limites et biais explicités
- Aucune PII dans les jeux d'entraînement non anonymisés
- Modèle protégé contre injections (LLM)
- Latence d'inférence < SLA
- Métrique métier (AUC, MAP, hallucination rate…) au-dessus du seuil
- Model registry mis à jour
- Version reproductible (données + code + hyperparams)
- Rollback vers version N-1 possible
- Product Owner + expert métier valident
- Explicabilité fournie si décisionnel
- Monitoring de drift en place
- Réentraînement planifié ou déclenché sur seuil
Firmware, objets connectés grand public, équipements médicaux.
- Code revu par ≥ 2 pairs
- MISRA / normes codage respectées
- Analyse statique OK
- Tests unitaires ≥ 90 %
- Tests HIL (Hardware In the Loop) verts
- Tests de robustesse (température, tension)
- Spécifications matérielles à jour
- Notes de version firmware rédigées
- Bootloader sécurisé
- Mises à jour signées
- Aucun port de debug ouvert en prod
- Consommation < budget énergétique
- Temps de démarrage < seuil défini
- Firmware signé et versionné
- OTA testée sur un pilote
- Product Owner + qualité valident sur produit réel
- Tests d'endurance 24 h passés
- Traçabilité complète (norme secteur)
- Compatibilité avec parc installé vérifiée
SCADA, MES, ligne de production connectée, jumeau numérique.
- Code revu
- Automate testé en simulation
- Rétrocompatibilité PLC assurée
- Tests en environnement iso-prod
- Tests de bascule / failover validés
- Tests de charge sur les capteurs
- Runbook opérateur à jour
- Plan de continuité documenté
- Formation opérateur préparée
- Segmentation IT/OT respectée
- Aucun accès distant non authentifié
- Audit de conformité IEC 62443 OK
- Latence temps réel < contrainte
- Aucune perte de trame capteur
- Fenêtre de maintenance planifiée
- Rollback matériel documenté
- Astreinte prévenue
- Responsable production valide la ligne
- KPIs OEE non dégradés
- Sécurité opérateur validée (HSE)
- Conformité réglementaire secteur (pharma, agro…) tracée
3. Checklist universelle interactive
Cette checklist minimale s'applique à presque tout produit logiciel. Cochez au fur et à mesure — c'est votre point de contrôle avant de déclarer un PBI « Done ».
4. Bonnes pratiques et pièges à éviter
- Affichée dans l'espace de l'équipe et visible en Sprint Planning.
- Revue à chaque Sprint Retrospective, renforcée avec la maturité.
- Alignée avec la DoD organisationnelle si elle existe.
- Critères mesurables (couverture, latence, seuils), pas subjectifs.
- Automatisée dans la CI dès que possible.
- Rédigée par le seul Scrum Master ou Product Owner.
- Rangée dans un wiki que personne ne consulte.
- Négociée à la baisse en fin de Sprint pour livrer plus.
- Assouplie par rapport à la DoD organisationnelle.
- Formulée en critères flous (« bien testé », « ça marche »).
5. Avant / après : d'une DoD faible à une DoD excellente
- • Le code compile.
- • Les tests passent (quand il y en a).
- • « Ça marche » sur le poste du dev.
- • Le ticket est fermé.
Résultat : bugs en production, dette technique croissante, PO qui perd confiance.
- ✔ Revue de code par un pair.
- ✔ Tests unitaires + intégration + non-régression verts en CI.
- ✔ Sécurité (SAST, dépendances) et performance dans les seuils.
- ✔ Documentation et notes de release à jour.
- ✔ Déployable en un clic, rollback documenté.
- ✔ PO valide l'Increment fonctionnellement.
Résultat : Increment potentiellement livrable, prévisibilité restaurée.
6. Tableaux comparatifs
Definition of Done vs Acceptance Criteria
| Critère | Definition of Done | Acceptance Criteria |
|---|---|---|
| Portée | Tous les Increments | Un PBI précis |
| Stabilité | Stable, évolue rarement | Spécifique à chaque PBI |
| Propriétaire | Scrum Team (Developers) | Product Owner |
| Nature | Standard de qualité | Comportement attendu |
Definition of Done vs Definition of Ready
| Critère | Definition of Done | Definition of Ready |
|---|---|---|
| Quand ? | Fin de développement | Entrée en Sprint Planning |
| Statut Scrum Guide | Obligatoire (engagement) | Optionnelle (pratique) |
| Objectif | Garantir la qualité livrée | Garantir la clarté d'un PBI |
Definition of Done vs Checklist qualité
| Critère | Definition of Done | Checklist qualité |
|---|---|---|
| Portée | Engagement Scrum de l'Increment | Outil opérationnel |
| Portée équipe | Toute la Scrum Team | Souvent QA / testeurs |
| Nature | Contrat qualité | Support de vérification |
Definition of Done vs Tests d'acceptation
| Critère | Definition of Done | Tests d'acceptation |
|---|---|---|
| Objet | État de l'Increment | Comportement d'une PBI |
| Format | Liste de critères qualité | Scénarios exécutables (BDD) |
| Fréquence | À chaque PBI terminé | À chaque exécution de la CI |
7. Les 10 erreurs les plus fréquentes
Compiler n'est pas produire un Increment. Sans tests, sans revue, sans qualité, ce n'est pas fait.
Le poste développeur n'est pas un environnement de vérité. Une DoD sérieuse impose une CI reproductible.
Reporter les tests transforme la dette en piège. Un PBI sans tests ne respecte pas la DoD.
Un Increment sans documentation entrave la maintenance et la transparence exigées par Scrum.
La revue par un pair détecte 60 % des défauts avant même les tests. La supprimer, c'est saboter la qualité.
Les Developers sont responsables de la qualité de l'Increment, sécurité comprise.
Un Increment doit être potentiellement livrable à la fin de chaque Sprint. Sinon, la DoD est incomplète.
Confusion classique avec les critères d'acceptation. La DoD est stable, les AC sont spécifiques au PBI.
La DoD est un contrat d'équipe. Une DoD individuelle brise la transparence et la cohérence.
Sans DoD explicite dès le Sprint 1, chaque Developer aura sa propre définition — et personne ne sera d'accord.
8. Cas concrets par secteur
Application de virement mobile.
Cryptographie validée, tests de charge 1000 tps, conformité PCI-DSS, audit interne signé.
Zéro incident critique en 18 mois.
Portail sinistres client.
Parcours accessible AAA, tests bout-en-bout sur 12 typologies de sinistre, RGPD tracé.
-40 % d'appels au call center.
Plateforme RH B2B multi-tenant.
Isolation tenant vérifiée, feature flag systématique, blue-green deploy.
Déploiements quotidiens sans downtime.
App fitness grand public.
Démarrage < 1.8 s, tests sur 20 devices, mode offline validé.
Note App Store passée de 3,9 à 4,7.
API publique de paiement.
P95 < 200 ms, contrat OpenAPI figé, tests de contrat consommateurs.
Aucun breaking change subi par les clients.
Ligne de production automobile.
Tests HIL, IEC 62443, rollback matériel validé, HSE signée.
Zéro arrêt de ligne dû au logiciel sur 12 mois.
Reporting financier consolidé.
Tests de fraîcheur, réconciliation avec ERP, lineage complet.
Fiabilité des chiffres validée par les commissaires aux comptes.
Refonte checkout haute saison.
Load test x3 pic Black Friday, A/B test, monitoring temps réel.
+12 % de taux de conversion, zéro incident.
9. Comment faire évoluer sa Definition of Done ?
La Definition of Done est vivante. Elle se renforce à mesure que l'équipe gagne en maturité, automatise ses contrôles et élargit son périmètre de responsabilité.
- Sprint 1Première DoD minimale — les fondamentaux : revue, tests, CI verte.
- RétrospectiveL'équipe identifie ce qui a manqué (sécurité ? doc ? performance ?).
- AméliorationAjout de 1 à 2 critères concrets et automatisés dans la CI.
- Nouvelle DoDVersion 2 partagée, affichée, appliquée dès le Sprint suivant.
- RétrospectiveOn mesure l'impact, on ajuste, on renforce.
- DoD matureStandards élevés, automatisés, Increment déployable en continu.
10. Copiez cette Definition of Done
Bloc Markdown prêt à coller dans Confluence, Notion, un README ou directement dans votre outil Scrum. Adaptez les seuils (couverture, latence…) à votre contexte.
# Definition of Done — Modèle universel
## Développement
- [ ] Code revu par au moins un pair
- [ ] Standards de codage respectés (linter OK)
- [ ] Aucune dette technique ajoutée sans ticket
## Tests
- [ ] Tests unitaires écrits (couverture ≥ 80 %)
- [ ] Tests d'intégration verts
- [ ] Tests de non-régression exécutés
## Qualité & sécurité
- [ ] Aucun bug bloquant ni critique
- [ ] Aucune vulnérabilité critique détectée
- [ ] Données sensibles protégées
## Documentation
- [ ] Documentation technique à jour
- [ ] Notes de version rédigées
- [ ] Documentation utilisateur mise à jour si nécessaire
## Performance
- [ ] Aucune régression de performance mesurée
- [ ] Seuils de performance respectés
## Déploiement
- [ ] Merge sans conflit
- [ ] Pipeline CI/CD verte
- [ ] Déployable en un clic, rollback documenté
## Validation
- [ ] Critères d'acceptation cochés
- [ ] Product Owner valide l'Increment
- [ ] Increment potentiellement livrable en production
11. Questions fréquentes
Les 15 questions les plus fréquentes sur les modèles de Definition of Done sont regroupées dans la section FAQ ci-dessous — elles complètent les modèles proposés plus haut.