Préparez un environnement de préproduction utile à la recette, avec des données de test, des intégrations isolées et des écarts de production connus.
Un responsable commercial valide un nouveau modèle de devis. Quelques minutes plus tard, un message de test arrive chez un vrai client parce que la préproduction utilisait encore le service d’envoi de production. L’application était séparée, mais une de ses dépendances ne l’était pas. Ce scénario hypothétique illustre pourquoi l’environnement de recette doit être examiné jusqu’à ses effets externes.
Commencez par écrire ce que vous voulez vérifier avant livraison. Une nouvelle règle de remise demande des cas métier précis. Une modification d’authentification demande des profils et des droits. Un test de charge exige des moyens adaptés. Un environnement unique ne répond pas forcément à tous ces usages.
Définir les différences acceptables
Le principe de parité entre développement et production de Twelve-Factor App encourage à limiter les différences entre environnements, notamment pour les services utilisés. Ce repère aide à décider quels écarts documenter. Une recette peut réussir avec une dépendance simplifiée et laisser intact le problème qui surviendra en production.
Conservez les versions des composants qui peuvent modifier le comportement testé. Si vous utilisez une base de données différente en recette, notez les fonctions et les migrations que vous ne pourrez pas valider fidèlement. Si la capacité est réduite, indiquez que les résultats ne constituent pas une preuve de tenue à la charge de production.
Tenez une liste courte des écarts volontaires et de leurs conséquences. Pour chaque livraison, le responsable technique doit pouvoir dire lesquels concernent la modification proposée. Cette liste peut tenir dans le dossier d’environnement ; elle doit évoluer avec la configuration.
Isoler les sorties vers l’extérieur
Inventoriez les services capables de produire un effet réel : envoi de messages, encaissement, synchronisation ERP, publication de fichiers ou mise à jour d’un stock. Affectez à chacun un mode de test et un contrôle de destination.
| Flux testé | Dispositif proposé | Preuve de vérification |
|---|---|---|
| Courriel | Boîte de capture dédiée | Message visible uniquement dans la recette |
| Paiement | Compte de test du prestataire | Transaction identifiable comme test |
| Synchronisation ERP | Instance isolée ou simulation documentée | Aucun objet créé dans l’ERP réel |
| Webhook sortant | Destination contrôlée | Requête retrouvée dans le récepteur de test |
Contrôlez ces destinations après chaque remise à zéro de l’environnement. Une copie de configuration peut réintroduire une adresse réelle. Ajoutez un contrôle explicite avant d’autoriser les essais des utilisateurs, avec le nom de la personne qui l’a réalisé.
Lorsque le fournisseur ne propose pas d’environnement de test, choisissez les cas que vous pouvez simuler et préparez séparément la vérification de production. Documentez ce qui reste non couvert, ainsi que la personne qui accepte ce risque avant livraison.
Préparer un jeu de données lisible
Construisez des fiches fictives représentant les situations utiles : client sans historique, devis avec remise, commande annulée ou article indisponible. Donnez-leur des noms qui permettent au responsable métier de comprendre immédiatement le scénario. Évitez un jeu entièrement aléatoire lorsque la recette porte sur des règles précises.
Attribuez à chaque scénario son résultat attendu. Une commande refusée peut être un test réussi si le refus correspond à la règle demandée. Les critères d’acceptation du logiciel métier doivent expliquer cette différence avant le début de la recette.
Prévoyez une méthode de réinitialisation pour rejouer les cas sans dépendre des modifications de la veille. Indiquez si elle efface toutes les données de recette et avertissez les personnes concernées avant de l’exécuter. Certaines équipes auront besoin de conserver des exemples en cours d’analyse dans un espace distinct.
Donner des comptes correspondant aux rôles réels
Un compte administrateur partagé ne permet pas de vérifier les droits d’un commercial ou d’un responsable de stock. Préparez les profils représentatifs avec leurs accès attendus. Faites tester également les refus : consulter le dossier d’une autre équipe, approuver sa propre demande ou modifier un devis déjà validé.
Identifiez visuellement l’environnement dans l’interface. Le domaine et une mention persistante doivent permettre de reconnaître la recette, même sur une page ouverte depuis un lien direct. Cette indication ne remplace pas l’isolement technique, mais elle aide les utilisateurs à signaler leurs observations au bon endroit.
Fixez une durée d’accès pour les intervenants occasionnels. À la clôture de la recette, révoquez les comptes devenus inutiles et conservez les résultats de validation dans le dossier de livraison.
Tester aussi le chemin de déploiement
Enregistrez la version livrée en préproduction et les opérations exécutées pour l’installer. Faites passer les migrations nécessaires par le mécanisme prévu pour la production. Si une correction manuelle devient indispensable, documentez-la puis décidez comment elle sera reproduite.
Un échec d’installation doit laisser des informations exploitables. Vérifiez l’accès aux journaux et la procédure de reprise. Le guide de retour arrière avec une base de données aide à préparer les situations où réinstaller le code précédent ne suffit pas.
Avant de déclarer la recette terminée, rassemblez la version testée, les scénarios réalisés et les réserves restantes. Une validation portant sur une version différente de celle destinée à la production doit être réexaminée. Le responsable métier peut alors accepter la livraison avec une liste explicite des points encore ouverts.