# Liste avant livraison et publication

## Utilisation

Marquez chaque point : réussi, à résoudre ou sans objet. Notez date, version, exemples et problèmes. Après un changement important, revérifiez les parties touchées.

Tous les projets utilisent 1 et 2 ; les sites ajoutent 3, puis 4 ou 5 si nécessaire. Paiements, données sensibles et activité critique demandent des contrôles spécifiques.

## 1. Objectif, sources et versions

- [ ] Public, objectif et exclusions sont clairs.
- [ ] Sources et dates sont correctes ; manques et contradictions sont listés.
- [ ] Originaux et version précédente sont récupérables.
- [ ] Publication, envoi, paiement ou suppression ont été validés par le responsable.

## 2. Résultat et usage

- [ ] Page ou fichier s’ouvre et le destinataire sait commencer.
- [ ] Chiffres recalculés, conclusions reliées aux sources, exemples fictifs signalés.
- [ ] Format, textes, images, liens et lisibilité à la taille réelle vérifiés.
- [ ] Un autre jeu normal a été essayé ; les manques sont signalés sans inventer de conclusion.
- [ ] Un processus récurrent précise entrées, étapes, sorties et validations humaines.

## 3. Page ou outil dans le navigateur

- [ ] Adresse finale accessible et HTTPS fonctionnel pour un site public.
- [ ] Lecture, saisie et clic possibles sur téléphone, sans masquage ni débordement.
- [ ] Parcours complet, rechargement, retour et liens principaux essayés.
- [ ] Champs vides, formats et bornes incorrects signalés ; calculs testés sur exemples.
- [ ] Aucun secret, compte de test ou document privé dans la page.

## 4. Serveur, API ou stockage

- [ ] Configuration et dépendances en ligne prêtes ; construction et démarrage documentés.
- [ ] Connexions, lectures et écritures réelles essayées ; données de test séparées.
- [ ] Délais dépassés, pannes et doubles envois gérés avec une explication à l’utilisateur.
- [ ] Erreurs consultables, sans secrets ni données personnelles dans les journaux.
- [ ] Sauvegarde et restauration connues ; retour possible après une publication ratée.

## 5. Comptes ou accès distincts

- [ ] Les données restreintes restent inaccessibles sans connexion.
- [ ] Deux comptes ont testé leurs propres droits de lecture et modification.
- [ ] Le serveur vérifie les droits en lecture et écriture, au-delà des boutons masqués.
- [ ] Déconnexion, lien direct ou changement d’identifiant ne dévoilent pas un autre compte.

## 6. Après livraison

- [ ] Un utilisateur concerné a essayé ; blocages et incompréhensions sont notés.
- [ ] Adresse ou fichier, mode d’emploi, problèmes connus et responsable des modifications sont conservés.
- [ ] Après la prochaine modification, le parcours principal sera essayé à nouveau.

Pour les documents, utilisez l’[exercice de comparaison](https://vibecoding.ivheli.com/fr/guides/ai-native-workflow/). Pour un site, reprenez le [parcours de démarrage](https://vibecoding.ivheli.com/fr/guides/zero-basis-first-website/).
