La nuit où notre automatisation a mal tourné

Dans la soirée du 24 au 25 octobre 2026, on a voulu automatiser l'envoi du formulaire de devis du site : dès qu'un visiteur le remplit, un document doit être généré et envoyé automatiquement, sans intervention manuelle.

Le problème, c'est qu'on a construit, codé et mis cette automatisation en ligne en une seule fois, directement sur le site réel visité par les internautes. On n'est jamais passés par une étape intermédiaire où on aurait pu la tester sans risque, à l'abri des visiteurs. On appelle ça une « préversion » : une copie temporaire du site, accessible seulement par une adresse spéciale, qui permet de vérifier que tout fonctionne avant de toucher au site public.

Sans cette étape, chaque problème a été découvert directement en conditions réelles. Il y en a eu deux dans la soirée :

• un bug qui cassait la mise en forme du document généré ;
• un service externe qui refusait certains appels techniques faits automatiquement par le serveur plutôt que par un navigateur.

Deux bugs réels, pas des caprices de l'IA : des erreurs de configuration, repérées et corrigées une par une, mais chaque fois après coup, sur le site en direct, avec notre client comme premier témoin un soir où il était déjà fatigué.

Le résultat : plusieurs allers-retours dans la soirée, la même catégorie d'erreur qui revenait, et un sentiment net de travail en silo plutôt qu'en équipe organisée. Une difficulté s'est ajoutée : pour chaque correction, l'équipe renvoyait au client l'intégralité de l'historique du projet, une méthode pensée pour une livraison unique, pas pour plusieurs échanges rapprochés dans la même soirée. Résultat : il devenait difficile de savoir, à un instant donné, quelle version exacte le client avait réellement entre les mains.

Ce qui rend cet épisode intéressant, c'est qu'on avait déjà vécu l'inverse. La construction du site statique lui-même (celui que vous êtes en train de lire) s'était bien déroulée, sans accroc comparable.

La différence ne tient pas aux outils, mais au circuit suivi. Pour le site statique, chaque étape avait un responsable et un point de contrôle avant de passer à la suivante : la personne qui construit n'est pas celle qui vérifie, et celle qui vérifie n'a pas participé à la construction, pour ne pas avoir un regard complaisant sur son propre travail. La procédure de mise en ligne, elle, a été écrite une fois, testée une fois, puis réutilisée à l'identique à chaque fois qu'il fallait republier le site.

Pour l'automatisation du devis, ce circuit a été court-circuité. On est allés tout droit du code à la production, sans vérification indépendante entre les deux. C'est exactement ce raccourci qui a transformé deux bugs ordinaires, le genre qu'on croise sur n'importe quel projet, en une mauvaise soirée.

Avant de changer quoi que ce soit, on s'est posé une question simple : est-ce qu'il manquait une compétence dans l'équipe ? La réponse est non. Chaque problème technique a été résolu correctement dès qu'on l'a pris au sérieux et qu'on l'a confié à la bonne personne. Le souci n'était donc pas une lacune de l'équipe, mais une étape de vérification qui a été sautée avant la mise en ligne.

On a aussi identifié un point plus structurel : personne n'avait, par écrit, la responsabilité formelle de cette partie précise du déploiement. Le rôle qui gère habituellement la mise en ligne du site couvre un autre hébergeur que celui utilisé pour cette automatisation. Faute de responsable désigné sur ce point, la façon de la déployer a été improvisée sur le moment, sous pression, plutôt que préparée à l'avance.

Le 25 octobre, la même équipe a repris l'automatisation avec un nouveau process, et la reprise a réussi.

Plus aucune mise en ligne directe sans étape intermédiaire. Chaque changement passe désormais par la préversion décrite plus haut, où l'on vérifie que tout fonctionne, avant de passer à la version visible par les internautes. Deux étapes distinctes, jamais fusionnées en une seule.

Une vérification indépendante sur toute automatisation, pas seulement sur le site lui-même. Jusqu'ici, seul le site statique bénéficiait d'un contrôle fait par quelqu'un d'autre que la personne qui l'avait construit. Ce principe s'étend maintenant à toute fonctionnalité automatisée, formulaire inclus.

Une procédure de mise en ligne écrite et testée pour cette automatisation précise. Comme pour le site statique, l'objectif est de documenter une fois la bonne façon de déployer, de la tester, puis de la suivre à l'identique à chaque mise à jour future, plutôt que de réinventer la méthode chaque soir.

Une façon plus claire d'échanger les fichiers pendant une même session de travail. Quand plusieurs corrections s'enchaînent rapidement, on évite désormais de repartir d'un historique complet à chaque fois : on transmet uniquement les fichiers précis qui ont changé, à partir d'un état déjà validé.

Une question reste ouverte, sans urgence : automatiser aussi la mise en ligne de cette brique pour supprimer toute étape manuelle côté client. Elle dépend d'un choix d'hébergement que le client tranchera quand il le souhaitera.

On pourrait choisir de ne raconter que les succès. Mais le vrai sujet de cet article n'est pas le bug d'un soir : c'est la méthode qui en ressort. Un incident révèle où se trouvent les vrais points de contrôle d'une organisation, et ce qu'il faut faire quand l'un d'eux a été oublié.

Ce qui a mal tourné n'était pas un manque de compétence, mais une étape de vérification sautée. Et ce qui s'est bien passé le lendemain, ce n'est pas une IA « plus intelligente », mais une équipe qui a remis en place le circuit qu'elle avait déjà validé ailleurs : construire, vérifier indépendamment, documenter, puis seulement publier.

C'est cette discipline-là qu'on applique maintenant à chaque automatisation que l'on livre, y compris chez nos clients. Vous avez un projet d'automatisation et vous voulez qu'il soit cadré de cette façon dès le départ ? Réservez un appel découverte gratuit de 30 minutes : on en parle ensemble.