L’essentiel
Une page d’accueil qui s’affiche ne prouve pas qu’une livraison est réussie. Les trois pannes les plus coûteuses après une mise en ligne sont invisibles depuis un navigateur : les pages cessent d’être indexées, les e-mails automatiques ne partent plus, les tâches planifiées ne tournent plus. Personne ne s’en aperçoit avant plusieurs semaines, et c’est souvent le client qui finit par le découvrir. Nous exécutons une recette après chaque mise en production et nous en remettons la preuve.
Les trois pannes que personne ne voit
L’indexation
Une directive noindex oubliée depuis la préproduction, un robots.txt déployé avec la mauvaise configuration, des anciennes URL non redirigées, une balise canonique qui pointe encore vers le domaine de recette. Le site fonctionne parfaitement pour un visiteur humain et disparaît progressivement de Google.
Quand personne ne contrôle, la détection arrive avec la baisse de trafic : le temps qu’elle devienne assez visible pour inquiéter quelqu’un, plusieurs semaines ont passé.
Les e-mails et les tâches automatiques
Un changement d’hébergement, une mise à jour de runtime, une variable d’environnement non reportée, et les envois s’arrêtent. Formulaires de contact, confirmations, relances, exports nocturnes, synchronisations, newsletters.
Le piège particulier : une fonction d’envoi qui retourne un succès n’a pas prouvé qu’un message est arrivé. Il faut vérifier la réception réelle, pas le code de retour.
Les écrans non couverts
Un correctif appliqué à une page, alors que le composant fautif est utilisé sur six autres. Le bug réapparaît ailleurs, et le client découvre les occurrences une par une.
C’est le symptôme d’une correction traitée au symptôme plutôt qu’à la cause. Cela se règle en identifiant les zones impactées avant de corriger, pas en relisant le site après.
Notre checklist de recette
Elle est dimensionnée au périmètre réellement touché par la livraison. Un correctif de style ne déclenche pas les mêmes contrôles qu’une migration d’hébergement.
1. Disponibilité
Codes de réponse sur les pages principales, absence d’erreurs serveur, certificat TLS et redirection vers HTTPS, redirections entre domaine racine et sous-domaine, journaux d’erreurs applicatives et erreurs JavaScript en console.
2. Parcours critiques
Navigation, formulaires de bout en bout, connexion et espace client s’ils existent, paiement le cas échéant, et les actions métier propres au projet. Testés sur mobile et sur ordinateur, pas seulement sur le poste du développeur.
3. E-mails
Envoi d’un message de test et vérification de sa réception effective, y compris dans les indésirables. Formulaires, notifications, e-mails transactionnels. Contrôle de la configuration d’envoi et des enregistrements d’authentification du domaine quand l’architecture a changé.
4. Tâches automatiques
Exécution effective des tâches planifiées, des files de traitement, des imports et des synchronisations, vérifiée dans les journaux et non supposée. Une tâche qui ne s’exécute plus ne produit aucune erreur visible : elle produit un silence.
5. Indexation et SEO technique
robots.txt, directives d’indexation, balises canoniques, sitemap, codes de réponse des URL stratégiques, redirections depuis les anciennes adresses. Puis suivi des erreurs d’indexation dans la Search Console les jours suivants.
Une nuance que nous énonçons toujours : vérifier qu’un site autorise l’indexation n’est pas vérifier qu’il est indexé. Le premier contrôle est immédiat, le second prend du temps.
6. Mesure
Présence et fonctionnement du suivi d’audience, événements de conversion déclenchés sur un parcours réel, comparaison du trafic et des erreurs avec la période de référence.
La preuve, pas la case cochée
Une checklist sans preuve ne vaut rien, parce qu’elle repose entièrement sur la rigueur de celui qui l’exécute un vendredi soir.
Nous transmettons un compte rendu horodaté au plus tard le jour ouvré suivant la mise en ligne. Il contient :
| Élément | Ce qui est fourni |
|---|---|
| Version déployée | Référence, date et heure de mise en production |
| Contrôles réalisés | La liste, avec leur résultat |
| Contrôles non réalisés | Nommés comme tels, jamais réputés réussis par défaut |
| Anomalies | Gravité, responsable, délai de correction |
| Preuves | Résultats de tests et journaux pertinents |
| Suite | Contrôles restant à faire et leur échéance |
Le point qui compte le plus est le troisième. Un contrôle non effectué doit apparaître comme non effectué. C’est exactement ce qui sépare une recette d’une formalité.
Les contrôles différés
Certaines pannes ne se voient pas dans l’heure qui suit une mise en ligne.
- À J+1 : nouvelle vérification des tâches qui ne tournent qu’une fois par jour, des e-mails différés, des erreurs serveur accumulées.
- À J+7, pour une migration ou un changement à risque : trafic organique, erreurs d’exploration, pages indexées, conversions.
Une migration qui semble réussie le jour même peut révéler sa perte d’indexation une semaine plus tard. C’est précisément la fenêtre pendant laquelle le problème reste réparable à moindre coût, et le sujet de la page sur le trafic effondré après une migration.
Ce que cette recette ne garantit pas
Nous préférons le dire avant plutôt que de le découvrir ensemble.
- Elle ne garantit pas l’absence de bugs. Elle garantit que les parcours critiques ont été testés et que le résultat est écrit quelque part.
- Elle ne garantit pas que Google réindexera rapidement. Elle garantit que rien, côté site, ne l’en empêche.
- Elle ne remplace pas une supervision continue. Une tâche peut tomber trois semaines après une livraison parfaite, et c’est le rôle du monitoring.
- Elle ne couvre que le périmètre réellement impacté. Auditer tout le site à chaque correctif serait facturé pour rien.
Pour un site que nous n’avons pas construit
La procédure s’applique aussi à un site existant, repris à un autre prestataire. Elle commence alors par un état des lieux : ce qui tourne, ce qui ne tourne plus, ce que personne ne surveille.
C’est souvent à ce moment qu’on découvre qu’une tâche planifiée est en échec depuis des mois sans qu’aucune alerte n’ait jamais été émise.
Ce sur quoi nous nous engageons
Ces points figurent dans nos contrats, ce ne sont pas des arguments commerciaux.
- Une recette est exécutée après chaque mise en production, dimensionnée au périmètre touché.
- Un compte rendu horodaté est transmis au plus tard le jour ouvré suivant, avec les contrôles non réalisés nommés comme tels.
- Une anomalie bloquante déclenche une alerte immédiate et, quand c’est techniquement possible, un retour à la version précédente plutôt qu’une correction dans l’urgence.
- Les contrôles répétitifs sont automatisés quand le projet le justifie, pour ne pas dépendre de la vigilance d’une personne un jour de fatigue. Voir la gouvernance technique.
- Nous refusons les missions qui ne correspondent pas à nos forces, notamment les très gros projets legacy complexes et les technologies trop éloignées de notre stack.
FAQ
Qu’est-ce qu’une recette post-livraison, concrètement ? L’exécution d’une liste de contrôles après chaque mise en production, portant sur la disponibilité, les parcours métier, les e-mails, les tâches automatiques, l’indexation et la mesure, suivie d’un compte rendu écrit qui en donne les résultats et les preuves. Elle se distingue de la recette fonctionnelle, qui valide avant livraison que les fonctionnalités commandées sont conformes.
Pourquoi un site peut-il fonctionner en apparence et être cassé ? Parce que l’affichage d’une page ne mobilise qu’une petite partie du système. L’indexation dépend de directives invisibles pour un visiteur, les e-mails dépendent d’un service d’envoi distinct, et les tâches planifiées s’exécutent sans interface. Les trois peuvent échouer silencieusement pendant que le site reste parfaitement consultable.
Comment vérifier qu’un prestataire fait vraiment cette recette ? Demandez-lui un exemple anonymisé de compte rendu de mise en production. Un prestataire qui en produit réellement en a sous la main. Demandez aussi ce qui se passe quand un contrôle échoue un vendredi soir : qui est alerté, et dans quel délai.
Faut-il automatiser ces contrôles ? Les contrôles répétitifs et objectifs, oui : disponibilité, codes de réponse, parcours critiques, exploration des URL. Ceux qui demandent un jugement, comme la pertinence d’une redirection ou la cohérence d’un contenu, restent humains. L’automatisation réduit la dépendance à la rigueur individuelle, elle ne la supprime pas.
Faisons l’état des lieux de votre site. Si vous avez eu une migration ou une refonte ces derniers mois, on regarde ensemble ce qui tourne encore et ce qui s’est arrêté sans prévenir.