Pourquoi une automatisation tombe-t-elle en panne ?

Presque jamais à cause de son propre code. Les causes réelles sont extérieures : un outil tiers qui modifie son interface, un mot de passe expiré, un quota dépassé, un format de fichier qui change chez un fournisseur, un serveur indisponible. C’est pourquoi une automatisation demande de l’exploitation : l’environnement autour d’elle bouge en permanence.

Comment savoir qu’un flux ne tourne plus ?

En exigeant de lui un signe de vie périodique, même quand il n’a rien fait. Un récapitulatif hebdomadaire indiquant « 43 documents traités » ou « rien à traiter cette semaine » permet de détecter l’arrêt. Sans ce signal, une absence d’activité ressemble exactement à une absence d’erreur — et c’est ainsi que les automatisations meurent sans témoin.

Faut-il un contrat de maintenance ?

Une forme de suivi est nécessaire, quel qu’en soit le nom. Ce qui compte, c’est que quelqu’un soit désigné pour réagir quand une alerte arrive, et que cette personne ait les accès pour le faire. Beaucoup d’automatisations abandonnées ne le sont pas parce qu’elles étaient mauvaises, mais parce que personne n’était responsable de leur survie.

Quel est le délai d’intervention en cas de panne ?

L’alerte part immédiatement, sans attendre que quelqu’un s’aperçoive de quoi que ce soit. Nous intervenons ensuite dans la journée ouvrée sur un flux critique, sous deux jours sur le reste. Mais le vrai filet de sécurité n’est pas notre délai : c’est la procédure de reprise remise à la livraison, qui dit à votre équipe quel geste manuel prend le relais en attendant. Un flux dont l’arrêt bloque l’entreprise est un flux mal conçu.

Que deviennent les éléments non traités pendant une panne ?

Ils attendent, et c’est un choix de conception délibéré. Nos flux enregistrent ce qu’ils ont déjà traité, de sorte qu’une reprise après incident ne produise ni doublon ni oubli — c’est le point qui casse le plus souvent dans les automatisations construites à la hâte. Rien n’est jamais supprimé à la source tant que le traitement n’est pas confirmé.

Que couvre exactement l’abonnement d’exploitation ?

La surveillance des flux, le traitement des incidents, l’adaptation quand un de vos outils change — une interface modifiée par un éditeur, une règle de place de marché, une mise à jour de logiciel — et un point périodique sur ce qui a tourné, ce qui a échoué, et ce qui mérite d’être automatisé ensuite. Ce qu’il ne couvre pas : la construction de nouveaux process, qui se chiffre séparément.

Que se passe-t-il si nous arrêtons de payer l’exploitation ?

Les flux continuent de tourner : ils vivent chez vous, sur vos comptes et vos serveurs, et nous ne coupons rien. Ce qui s’arrête, c’est la surveillance et l’adaptation. En pratique, un flux non suivi tient quelques mois puis dérive quand un outil tiers change — sans que personne le remarque tout de suite. Une page entière de ce site est consacrée à ce scénario, précisément parce qu’il mérite d’être su avant de signer.

Question

Que se passe-t-il quand une automatisation tombe en panne ?

Une automatisation correctement conçue échoue bruyamment : elle s’arrête, elle prévient une personne nommée, et elle laisse une trace de ce qu’elle avait fait. Une procédure écrite indique comment traiter les dossiers en attente à la main. Le scénario à éviter absolument est la panne silencieuse — un flux qui cesse de fonctionner sans que personne ne s’en aperçoive avant plusieurs semaines.

Les trois façons d’échouer

L’échec bruyant. Le flux s’arrête, prévient, et laisse tout en l’état. C’est le bon comportement. Quelqu’un est averti, traite les dossiers en attente à la main, et corrige la cause.

L’échec partiel. Le flux continue mais traite mal une partie des cas. C’est plus gênant, parce que les erreurs s’accumulent en silence. C’est ce que les contrôles de cohérence servent à détecter.

L’échec silencieux. Le flux ne tourne plus, et rien ne se passe. Pas d’erreur, pas d’alerte, rien. On s’en aperçoit trois semaines plus tard, quand un client demande pourquoi il n’a jamais reçu sa facture.

Le troisième est de loin le plus coûteux, et c’est celui qu’on rencontre le plus souvent dans les automatisations construites sans méthode.

Ce qu’on met en place systématiquement

Un signe de vie. Chaque flux critique produit un récapitulatif périodique, même vide. C’est ce qui distingue « rien à faire » de « je ne fonctionne plus ».

Une alerte nominative. Pas une adresse générique que personne ne lit : une personne, désignée, avec un remplaçant identifié.

Une procédure de reprise. Un document d’une page qui dit : voici ce que fait ce flux, voici comment le faire à la main pendant qu’il est arrêté, voici qui appeler. Écrit avant la mise en production, pas le jour de la panne.

Un journal. Ce qui a été traité, quand, avec quel résultat. Sans journal, on ne sait pas où le flux s’est arrêté, et on ne sait donc pas quels dossiers reprendre.

Un point d’arrêt propre. Le flux doit pouvoir être coupé sans laisser d’opération à moitié faite.

Ce qui rend une panne grave

Ce n’est pas la durée de l’interruption : c’est l’absence d’alternative.

Si le process peut être fait à la main pendant trois jours, une panne de trois jours est un désagrément. Si plus personne ne sait le faire à la main parce que l’automate est en place depuis deux ans, c’est un incident majeur.

C’est la raison pour laquelle nous documentons toujours la reprise manuelle, y compris — et surtout — quand le client trouve que c’est une précaution excessive. C’est le genre de document qui ne sert à rien pendant deux ans, puis qui vaut son poids en or un mardi matin.

Notre engagement

Un automate est livré avec son mode d’emploi en cas de panne. Si personne ne sait quoi faire quand il s’arrête, il n’est pas terminé.

Ce n’est pas une formule commerciale : c’est un critère de livraison. Un flux sans procédure de reprise n’est pas facturable, parce qu’il n’est pas fini.

Une interface tierce change
Corrigé, flux relancé
Un mot de passe expire
Renouvelé, rien de perdu
Un format évolue
Adapté, documenté

Chaque incident produit une alerte, une reprise et une ligne dans le journal. Personne ne le découvre trois mois plus tard.

Questions fréquentes

Pourquoi une automatisation tombe-t-elle en panne ?: Presque jamais à cause de son propre code. Les causes réelles sont extérieures : un outil tiers qui modifie son interface, un mot de passe expiré, un quota dépassé, un format de fichier qui change chez un fournisseur, un serveur indisponible. C’est pourquoi une automatisation demande de l’exploitation : l’environnement autour d’elle bouge en permanence.
Comment savoir qu’un flux ne tourne plus ?: En exigeant de lui un signe de vie périodique, même quand il n’a rien fait. Un récapitulatif hebdomadaire indiquant « 43 documents traités » ou « rien à traiter cette semaine » permet de détecter l’arrêt. Sans ce signal, une absence d’activité ressemble exactement à une absence d’erreur — et c’est ainsi que les automatisations meurent sans témoin.
Faut-il un contrat de maintenance ?: Une forme de suivi est nécessaire, quel qu’en soit le nom. Ce qui compte, c’est que quelqu’un soit désigné pour réagir quand une alerte arrive, et que cette personne ait les accès pour le faire. Beaucoup d’automatisations abandonnées ne le sont pas parce qu’elles étaient mauvaises, mais parce que personne n’était responsable de leur survie.
Quel est le délai d’intervention en cas de panne ?: L’alerte part immédiatement, sans attendre que quelqu’un s’aperçoive de quoi que ce soit. Nous intervenons ensuite dans la journée ouvrée sur un flux critique, sous deux jours sur le reste. Mais le vrai filet de sécurité n’est pas notre délai : c’est la procédure de reprise remise à la livraison, qui dit à votre équipe quel geste manuel prend le relais en attendant. Un flux dont l’arrêt bloque l’entreprise est un flux mal conçu.
Que deviennent les éléments non traités pendant une panne ?: Ils attendent, et c’est un choix de conception délibéré. Nos flux enregistrent ce qu’ils ont déjà traité, de sorte qu’une reprise après incident ne produise ni doublon ni oubli — c’est le point qui casse le plus souvent dans les automatisations construites à la hâte. Rien n’est jamais supprimé à la source tant que le traitement n’est pas confirmé.
Que couvre exactement l’abonnement d’exploitation ?: La surveillance des flux, le traitement des incidents, l’adaptation quand un de vos outils change — une interface modifiée par un éditeur, une règle de place de marché, une mise à jour de logiciel — et un point périodique sur ce qui a tourné, ce qui a échoué, et ce qui mérite d’être automatisé ensuite. Ce qu’il ne couvre pas : la construction de nouveaux process, qui se chiffre séparément.
Que se passe-t-il si nous arrêtons de payer l’exploitation ?: Les flux continuent de tourner : ils vivent chez vous, sur vos comptes et vos serveurs, et nous ne coupons rien. Ce qui s’arrête, c’est la surveillance et l’adaptation. En pratique, un flux non suivi tient quelques mois puis dérive quand un outil tiers change — sans que personne le remarque tout de suite. Une page entière de ce site est consacrée à ce scénario, précisément parce qu’il mérite d’être su avant de signer.

Une question qui n’est pas là ?

Posez-la. Si la réponse intéresse d’autres personnes, elle deviendra une page.

Écrire

Parlons-en

Un process, pour commencer

Celui qui vous agace le plus, ou celui qui coûte le plus. Dites-nous en deux phrases qui le fait, combien de fois par semaine, et avec quels outils. Nous vous dirons franchement s’il mérite d’être automatisé — y compris quand la réponse est non.

Réponse garantie sous 24 heures
Un premier échange d’une demi-heure, sans engagement
Aucun formulaire tiers : votre message part par votre messagerie

Ou directement : nicolas@oli-via-net.fr· 06 89 96 40 79

Que se passe-t-il quand une automatisation tombe en panne ?