Une automatisation qui tombe en panne sans alerte peut coûter plus cher qu'une tâche faite à la main. Nous faisons fonctionner quarante-quatre services, décrits dans le code, contrôlés chaque jour, avec des réparations automatiques limitées à ce qui est réversible.
Entre le sourcing, la rédaction, l'envoi, la capture des réponses, le scan de visibilité, la génération documentaire, les démonstrations prospects et l'intranet, Lumivi fait tourner quarante-quatre services. Le 16 septembre 2026, le constat était net : « des bouts d'infra de partout, rien d'uniforme ». Seize services installés à la main, huit façons différentes de déployer, six conventions de nommage. Et les pannes les plus coûteuses étaient silencieuses : des exécutions figées douze jours, un quota épuisé par un tiers, un contrôle jamais exécuté au bon moment.
Les adresses internes, les secrets et la topologie détaillée ne sont pas publiés. Les chiffres sont ceux mesurés sur le cluster de production aux dates indiquées.
Comment une équipe de deux personnes exploite-t-elle quarante-quatre services sans astreinte, sans oublier une brique, et sans qu'une panne silencieuse ne dure des jours ?
Les contraintes, les données et les garde-fous pris en compte pour concevoir l'outil.
Les trois pannes du 1er septembre 2026 n'ont déclenché aucune erreur : une exécution qui ne finit jamais, un quota épuisé par un autre service, un contrôle exécuté au mauvais moment avec un résultat vert et faux. Les détecteurs mesurent désormais la cadence, la durée et les résultats, pas seulement les erreurs.
On aurait pu demander à un modèle « regarde si quelque chose cloche ». Une alerte doit être reproductible : dix détecteurs écrits, seuils en tête de fichier, testés. Le modèle n'est appelé qu'après une alerte d'un détecteur, pour diagnostiquer et rédiger.
Le contrôleur ne peut faire que deux choses seul, parce qu'elles se défont. Réactiver un workflow qui envoie des mails aurait pu expédier une rafale de rattrapage : le geste est refusé si le workflow contient un nœud d'envoi. Pour tout le reste, le contrôleur décrit le problème sans agir.
Seize services installés à la main n'auraient pas été recréés en cas de reconstruction de l'infrastructure. Ils ont été intégrés un par un dans le code, avec leurs scripts rapatriés dans le dépôt. Un contrôleur signale désormais tout service installé hors du code.
Nous avions huit façons différentes de construire et de déployer un service ; elles ont été remplacées par une seule : construction à chaque fusion sur la branche principale, image nommée par son empreinte, application ciblée.
L'intranet, les applications historiques du dépôt d'infrastructure et un pilote séparé ne sont pas encore sur le socle unique. Ils y passent un par un, en coordination avec l'associé qui les porte.
La situation avant le projet, puis après.
mesurés sur le cluster le 16 septembre 2026.
en une soirée, le 16 septembre 2026, avec onze services alignés sur le nommage unique.
pour les automatisations n8n, seuils testables, modèle appelé seulement sur anomalie.
parce que réversibles, et refusés dès qu'un envoi est en jeu.
écart entre le cluster et le code, mail si écart, point le lundi.
Les résultats se mesurent dans la durée. Voici les gains visés et ce qui n'est pas encore mesuré.
deux personnes qui exploitent quarante-quatre services sans astreinte
des pannes sans message d'erreur repérées le matin même
un cluster recréable à l'identique depuis le code
une méthode de livraison unique pour tous les services
Ce qui n'est pas mesuré à ce stade. Le temps d'exploitation économisé n'est pas mesuré. Le socle unique date du 16 septembre 2026 : l'intranet et quelques applications historiques ne l'ont pas encore rejoint.
Une PME qui accumule des automatisations doit vérifier qu'elles fonctionnent toujours. Trois règles s'appliquent : tout décrire dans le code, détecter les pannes par du code et ne laisser la machine réparer que ce qui peut être annulé.
Les principaux composants, décrits sans donnée confidentielle.
Kubernetes managé OVH en France, 44 services, namespaces par usage, agents sans interface dans un namespace dédié.
Terraform avec un module applicatif unique, adoption par import, étiquette de gestion, secrets hors dépôt.
GitLab CI, un patron de construction pour tous les services, image nommée main-empreinte, scan de vulnérabilités bloquant.
infra-doctor à 7 h 20, n8n-doctor avec dix détecteurs et deux gestes en liste blanche, placement-doctor à 7 h 05, chien de garde de l'intranet horaire, audit de code automatique.
Mail via Microsoft Graph sur anomalie seulement, point d'ensemble le lundi, cartes Teams pour les événements commerciaux.
Un détecteur écrit en code la repère le matin même, y compris si elle échoue sans erreur (exécution figée, quota épuisé, contrôle sauté). Un modèle diagnostique et rédige un rapport. Si la réparation est réversible, elle est faite automatiquement ; sinon elle est décrite et un humain tranche.
Parce qu'une réparation irréversible sur un système qui envoie des mails peut expédier une rafale. Les réparations automatiques sont limitées aux actions réversibles : deux gestes autorisés, chacun revérifiant ses conditions, et refus dès qu'un envoi est en jeu.
Tout est décrit en Terraform, livré par une chaîne unique, nommé de la même façon. Un contrôleur passe chaque matin à 7 h 20 et signale tout écart entre le cluster et le code, y compris un service installé à la main.
Oui, à l'échelle de ses automatisations : les mêmes trois règles s'appliquent à cinq workflows n8n comme à quarante-quatre services. C'est ce qu'on met en place chez les clients à qui on livre des automatisations, pour qu'elles tiennent après notre départ.
Le diagnostic gratuit part de vos processus, de vos outils et des tâches qui vous font perdre du temps, puis permet de décider si une démonstration ou un audit est utile.