Intelligence artificielle

Une automatisation en service : ce qu’elle coûte à garder

Le jour où elle fonctionne n’est pas la fin du projet, c’est le début de la facture. Ce qu’il faut savoir avant de mettre la première en production.

Publié le 24 juin 2026 — Algeria Agency

Une automatisation est presque toujours vendue et achetée comme un objet : elle est construite, elle est livrée, elle fonctionne, on passe à autre chose. C’est ce que suggère le devis, qui porte une date de fin et un montant unique.

Ce n’est pas ce qu’elle est. Une automatisation est un employé silencieux qui ne prend pas de congés, ne dit jamais qu’il est débordé, et cesse parfois de travailler sans le signaler à personne. Elle a un coût de fonctionnement, elle a besoin d’être regardée, et elle vieillit — non pas parce qu’elle se dégrade, mais parce que le monde autour d’elle bouge.

Cet article traite de l’après. Ce qui se paie une fois la mise en service faite, ce qui change sous vos pieds, la panne qui ne fait pas de bruit, le mois où le volume double, la personne qui part, et la décision d’en éteindre une. L’article qui l’accompagne traite de la décision d’automatiser et du contrôle qu’on garde en le faisant — le tri entre ce qui est rattrapable et ce qui ne l’est pas, le journal, l’interrupteur — et rien de cela n’est repris ici.

Un seul chiffre y figure, et il ne porte pas sur l’automatisation. Il porte sur la taille des entreprises algériennes, parce que c’est lui qui décide s’il y a quelqu’un pour la surveiller.

Le jour où elle marche n’est pas la fin

La mise en service est le moment où l’on cesse de payer le développement et où l’on commence à payer l’exploitation. Les deux sont réels, un seul apparaît sur le devis, et l’écart entre les deux est ce qui produit la phrase « on ne s’attendait pas à ça » six mois plus tard.

Cela n’a rien de propre à l’intelligence artificielle ni au logiciel. Une camionnette de livraison s’achète une fois et se paie chaque mois — carburant, entretien, assurance, quelqu’un pour la conduire. Personne ne s’en étonne parce que la camionnette est visible. Une automatisation est invisible, et l’invisible est facile à oublier au budget.

La différence pratique est qu’une camionnette qui tombe en panne se signale immédiatement : elle ne part pas le matin. Une automatisation en panne continue d’exister, son écran d’administration s’ouvre normalement, et elle ne fait simplement plus ce pour quoi elle a été construite. Personne ne l’apprend avant que le premier client se plaigne.

Il vaut donc mieux poser la question au moment du devis, quand la réponse ne coûte rien : combien cela coûte-t-il par mois de la garder en marche, qui le regarde, et à quoi voit-on qu’elle ne fonctionne plus ? Un fournisseur qui n’a pas de réponse à ces trois questions n’a pas fini de concevoir le système, il a fini de le construire.

Qui la regarde, et la réponse la plus fréquente

Toute la littérature sur l’automatisation suppose implicitement qu’une deuxième personne existe : celle qui reçoit l’alerte, celle qui reprend la main, celle qui remarque que le rapport du lundi n’est pas arrivé. Cette supposition est fausse pour la grande majorité des entreprises de ce pays.

Le registre du commerce compte 2 419 913 opérateurs inscrits, dont 2 145 557 personnes physiques : environ neuf sur dix. Une personne physique inscrite au registre n’a pas nécessairement zéro salarié, mais elle a un ordre de grandeur d’écart avec une société qui dispose d’un responsable informatique. L’entreprise médiane ici est une personne, et cette personne est déjà en train de faire autre chose.

La conséquence est directe et rarement tirée : si votre automatisation a besoin d’être surveillée pour être fiable, elle n’est pas fiable, parce que personne ne la surveillera. Ce n’est pas de la négligence, c’est de l’arithmétique. Concevoir en supposant un surveillant, c’est concevoir pour une entreprise qui n’est pas celle du client.

Ce que cela impose est une préférence nette pour les systèmes qui se plaignent eux-mêmes plutôt que pour ceux qu’il faut aller regarder. Une automatisation qui envoie un message quand elle n’a rien fait depuis deux jours vaut mieux qu’un tableau de bord magnifique que personne n’ouvre — et le second est plus facile à vendre, ce qui explique sa fréquence.

Opérateurs inscrits au registre du commerce algérien, par forme juridique

Personnes physiques2 145 557
Personnes morales274 356

CNRC, situation au 10 décembre 2025

Trois coûts qui ne sont pas du développement

Le premier est l’usage : chaque appel à un modèle se paie au volume de texte lu et écrit. Il est faible par unité et proportionnel à l’activité, ce qui est la bonne nouvelle — une automatisation qui coûte cher est une automatisation qui travaille — et il est la seule ligne que la plupart des gens anticipent.

Le deuxième est l’hébergement et la connexion : la machine qui exécute le travail, le service qui l’ordonnance, les abonnements aux outils que l’automatisation relie entre eux. Cette ligne est fixe, elle ne baisse pas quand l’activité baisse, et elle est celle qu’on découvre en janvier en regardant les prélèvements de l’année.

Le troisième n’est pas une ligne comptable et c’est le plus lourd : le temps humain de réparation. Le format d’export change, le fournisseur ajoute une colonne, un mot de passe expire. Chacun de ces incidents coûte une demi-journée à quelqu’un, ils arrivent quelques fois par an, et ils n’apparaissent nulle part parce que le temps interne ne se facture pas.

Nous ne publions pas de grille de ces montants, et c’est délibéré. Les prix des modèles sont révisés plusieurs fois par an — un tableau publié aujourd’hui serait faux avant que cet article ait une saison — et le reste dépend entièrement du volume et des outils déjà en place. Ce qui se transmet est la forme : une ligne variable, une ligne fixe, et une réserve de temps.

Ce qui change sous vos pieds

Une automatisation ne se dégrade pas toute seule. Le code qui fonctionnait lundi fonctionne encore le lundi suivant. Ce qui change, ce sont les choses auxquelles elle est attachée, et elle est attachée à beaucoup de choses qui ne vous appartiennent pas.

Les cas les plus fréquents sont ennuyeux et sans gloire. Un fournisseur modifie le format de son fichier d’export. Une plateforme change ses règles d’envoi de messages. Un site que l’automatisation consultait refait ses pages. Une clé d’accès arrive à expiration parce que quelqu’un a fixé une durée d’un an et que l’année est passée.

Aucun de ces événements n’est prévisible individuellement, et leur fréquence globale l’est très bien : comptez quelques interruptions par an et par intégration. Une automatisation qui relie quatre outils est exposée à quatre calendriers de décisions sur lesquels vous n’avez aucune prise, ce qui est l’argument le plus solide en faveur d’en relier peu.

La conclusion pratique n’est pas d’éviter les intégrations, c’est de savoir lesquelles vous avez. Une liste écrite des services dont dépend l’automatisation, avec pour chacun ce qui casse s’il change, se rédige en vingt minutes le jour de la livraison et ne se rédige jamais après, quand elle serait le plus utile.

La panne qui ne fait pas de bruit

La panne bruyante est la bonne : le système s’arrête, une erreur s’affiche, quelqu’un appelle. Elle se répare le jour même et ne coûte que le dérangement. Ce n’est pas celle qui fait mal.

La panne silencieuse est celle où l’automatisation continue de s’exécuter et ne traite plus rien. Le fichier attendu est vide, alors elle importe zéro ligne — sans erreur, puisque zéro ligne est un résultat valide. Le rapport part chaque lundi et il est calculé sur des données arrêtées trois semaines plus tôt. Tout est vert et rien n’avance.

Le remède tient en une idée simple et rarement appliquée : surveiller le travail accompli, pas l’absence d’erreur. Une automatisation qui traite habituellement entre trente et cent lignes par jour doit se plaindre quand elle en traite zéro, et non attendre qu’un incident se déclare. Le seuil n’a pas besoin d’être fin, il a besoin d’exister.

Ce contrôle est l’un des rares qui se rentabilise immédiatement, parce que la panne silencieuse se mesure en semaines. Une panne bruyante coûte une demi-journée ; une panne silencieuse découverte au bout d’un mois coûte un mois de données à reconstruire, et parfois des clients à qui l’on n’a rien envoyé sans le savoir. Le contrôle qui l’attrape le plus tôt est le relevé quotidien de ce que l’automatisation a mis de côté.

L’alerte que plus personne ne lit

La réponse naturelle aux deux sections précédentes est d’ajouter des alertes, et c’est la manière la plus courante de fabriquer un système que personne ne surveille. Une alerte qui se déclenche souvent devient un bruit de fond, et un bruit de fond s’ignore parfaitement au bout de deux semaines.

Le mécanisme est le même que celui du klaxon de recul d’un chariot élévateur : la première semaine tout le monde se retourne, la troisième plus personne. Il ne s’agit pas d’un défaut d’attention, mais d’une adaptation normale à un signal qui n’a jamais rien annoncé d’important.

La règle qui tient est qu’une alerte doit demander une action et une seule. Si le destinataire ne peut rien faire en la lisant, ce n’est pas une alerte, c’est une information, et elle appartient à un rapport hebdomadaire. La question à poser pour chaque alerte est : que fait la personne qui la reçoit, dans les dix minutes ?

Une automatisation bien réglée envoie très peu de messages, et il vaut mieux en recevoir un par mois qui compte que douze par jour qui ne comptent pas. Si le nombre d’alertes hebdomadaires dépasse ce qu’une personne peut traiter dans sa journée, le système ne prévient plus, il se décharge sur son lecteur.

Le mois où le volume double

Les automatisations sont réglées sur l’activité du moment où elles ont été construites, et l’activité de ce marché n’est pas plate. Le Ramadan, l’Aïd, la rentrée scolaire et les soldes produisent des semaines qui ne ressemblent à aucune autre, et c’est exactement quand une automatisation est le plus utile qu’elle est le plus sollicitée.

Les points de rupture sont rarement là où on les attend. Ce n’est presque jamais la puissance de calcul ; c’est une limite de nombre d’appels par minute chez un fournisseur, une boîte mail qui refuse d’envoyer au-delà d’un certain volume quotidien, un quota de messages sur une plateforme de discussion. Ces limites sont écrites dans des documents que personne ne lit avant de les atteindre.

Le test coûte une heure et se fait à froid : prenez le volume du mois le plus chargé de l’an dernier, multipliez-le par deux, et demandez au fournisseur ce qui se passe à ce niveau. La réponse est souvent qu’il faut prévenir à l’avance ou changer de formule, et ces deux choses se font en décembre bien plus facilement qu’un jour de pointe.

Le comportement en cas de dépassement compte autant que la limite. Une automatisation qui refuse proprement et reprend le lendemain est acceptable ; une qui perd silencieusement les éléments qu’elle n’a pas pu traiter ne l’est pas, et la différence entre les deux est une décision de conception qui ne se voit pas tant que le seuil n’est pas franchi.

La personne qui part

Toute automatisation a un parent : la personne qui l’a demandée, qui sait pourquoi elle existe et ce qu’elle fait des cas bizarres. Quand cette personne change de poste ou quitte l’entreprise, le système ne s’arrête pas — il devient inexplicable, ce qui est pire, parce qu’il continue à agir.

L’état qui suit est reconnaissable. Plus personne ne sait pourquoi une règle exclut les commandes d’un certain client, personne n’ose la retirer, et tout le monde travaille autour. L’automatisation devient un objet du décor que l’on contourne, et le contournement finit par coûter plus cher que le processus manuel d’origine.

Ce qui l’évite n’est pas une documentation technique, que personne ne lit et qui vieillit mal. C’est une page. À quoi sert cette automatisation, qu’est-ce qui la déclenche, qu’est-ce qu’elle touche, qui appeler quand elle s’arrête, et pourquoi les trois règles bizarres sont là. Une page tient à jour ; un manuel non.

Le moment de l’écrire est la livraison, et personne ne le fait à ce moment-là parce que tout est frais et paraît évident. C’est précisément la raison : ce qui est évident aujourd’hui est ce qui sera perdu, parce que personne ne pense à noter ce que tout le monde sait.

La revue trimestrielle, en trente minutes

Une automatisation n’a pas besoin d’une réunion hebdomadaire — elle n’a rien à raconter la plupart des semaines. Elle a besoin d’un rendez-vous rare et régulier, quatre fois par an, avec un ordre du jour fixe et court. Trente minutes suffisent pour tout un parc de petite taille.

Quatre questions, dans cet ordre. Qu’a-t-elle fait ce trimestre, en volume ? Combien de fois a-t-il fallu intervenir à la main, et pourquoi ? Qu’est-ce qui a changé chez les fournisseurs auxquels elle est attachée ? Et le processus qu’elle exécute est-il encore le processus réel de l’entreprise ?

La quatrième question est celle qui rapporte le plus et celle que l’on saute. Les entreprises changent leur manière de travailler sans annoncer les changements, et une automatisation fidèle à un processus abandonné il y a huit mois produit un travail impeccable dont personne n’a plus l’usage — le cas le plus coûteux de toute cette page.

Le compte rendu utile tient en quatre lignes dans le même fichier, trimestre après trimestre. Sa valeur n’est pas dans la ligne du jour mais dans la série : au bout d’un an, les interventions manuelles répétées sautent aux yeux, et ce sont elles qui désignent la prochaine chose à corriger, sans qu’il ait fallu y réfléchir.

Quand il faut l’éteindre

Certaines automatisations doivent être retirées, et c’est une décision saine plutôt qu’un aveu d’échec. Le processus a disparu, l’outil qu’elle alimentait a été remplacé, le volume est tombé à trois cas par mois qui se traitent plus vite à la main que la surveillance ne coûte.

Ce qui empêche de le faire est le prix payé pour la construire. C’est un raisonnement qui se comprend et qui est faux : l’argent dépensé l’est dans tous les cas, et la seule question qui vaut est de savoir si la garder coûte plus qu’elle ne rapporte à partir d’aujourd’hui. Le passé n’entre pas dans ce calcul.

L’extinction se fait proprement et pas en supprimant. On la désactive, on garde le code et les données trois mois, on prévient les gens qui recevaient ses envois — il y en a presque toujours un que personne n’avait recensé — et on note la date. Une automatisation supprimée un vendredi soir est un incident du lundi matin.

Il faut aussi vérifier ce qui s’appuyait sur elle sans le dire. Une automatisation en alimente souvent une autre, ou remplit un fichier qu’une personne utilise dans son coin depuis deux ans. L’arrêt révèle ces dépendances mieux que n’importe quel schéma, ce qui est un argument pour l’arrêter d’abord et supprimer ensuite.

Reprendre une automatisation héritée

Le cas le plus fréquent n’est pas d’en construire une, c’est d’en trouver une en place, écrite par quelqu’un qui n’est plus là, dont personne ne connaît le fonctionnement et que tout le monde craint de toucher. Le réflexe est de la réécrire, et c’est presque toujours le mauvais.

La première chose à établir est ce qu’elle fait réellement, qui n’est pas ce qu’on croit qu’elle fait. Ce qui la déclenche, ce qu’elle lit, ce qu’elle écrit, à qui elle envoie. Cette liste s’obtient en observant pendant deux semaines, sans rien modifier, et elle est presque toujours plus longue que la description qu’on vous en a donnée.

La deuxième est de savoir ce qui dépend d’elle en aval, et c’est là que se trouvent les surprises. Une automatisation ancienne a eu le temps de devenir la source de quelque chose : un fichier qu’un comptable ouvre chaque mois, un champ qu’une autre automatisation lit. Réécrire sans ce recensement, c’est réparer une chose et en casser trois.

Ensuite seulement, et souvent la réponse est de ne pas la réécrire. Une automatisation laide qui fonctionne depuis trois ans a été corrigée par la réalité un nombre incalculable de fois, et chaque règle bizarre qu’elle contient est le souvenir d’un cas réel. La réécriture propre les perd toutes et les redécouvre une par une, en production.

Ce que nous faisons, et ce que nous refusons

Ce que nous prenons en charge est délimité : concevoir l’automatisation avec la personne qui fait le travail aujourd’hui, l’installer avec ses contrôles de volume et sa page d’explication, et rester joignables pendant les premières semaines, qui sont celles où les cas non prévus se présentent tous.

Nous ne vendons pas de contrat de maintenance mensuel sur une automatisation qu’un client peut surveiller lui-même, et c’est un refus qui nous coûte. La plupart des systèmes que nous installons n’ont besoin de personne entre deux revues trimestrielles ; facturer une présence permanente sur ces systèmes serait vendre une assurance contre un risque que nous avons été payés pour supprimer.

Nous ne prenons pas non plus un processus dont le responsable ne peut pas dire à quoi il sert. Ce n’est pas une exigence de méthode : un processus que personne ne sait justifier est un processus que personne ne validera, et l’automatiser produit une machine qui exécute fidèlement quelque chose que l’entreprise avait cessé de vouloir.

Enfin, nous ne reprendrons pas devant vous le gain de temps obtenu chez un autre client. Ce chiffre est réel, il a été mesuré, et il est valide pour l’entreprise où il a été relevé et pour aucune autre : il dépend du volume, des outils déjà en place et de la manière dont les gens travaillent. Le seul chiffre qui vaut pour vous est celui que vous obtiendrez en chronométrant une semaine du processus concerné, et il vous appartient de le mesurer avant de nous croire.

Questions fréquentes

Combien coûte une automatisation par mois une fois installée ?

Trois lignes, dont une seule est une facture. L’usage des modèles, proportionnel au volume et généralement la plus petite. L’hébergement et les abonnements des outils reliés, fixe. Et le temps de réparation quand un fournisseur change quelque chose — quelques demi-journées par an, qui n’apparaissent nulle part parce que le temps interne ne se facture pas. Nous ne publions pas de grille : les prix des modèles sont révisés plusieurs fois par an et le reste dépend entièrement de vos volumes.

Comment savoir qu’une automatisation est en panne ?

En surveillant ce qu’elle fait, pas l’absence d’erreur. La panne dangereuse est celle où tout est vert et rien n’est traité : le fichier attendu est vide, zéro ligne importée est un résultat valide, et le rapport continue de partir. Réglez un seuil de volume — « elle traite d’habitude entre trente et cent lignes par jour, qu’elle se plaigne à zéro ». Le seuil n’a pas besoin d’être fin, il a besoin d’exister.

Nous n’avons personne à mettre dessus. Est-ce éliminatoire ?

Non, mais cela change ce qu’il faut construire. Neuf opérateurs inscrits sur dix en Algérie sont des personnes physiques, donc l’absence de surveillant est le cas normal et pas l’exception. La conséquence est de préférer les systèmes qui se plaignent eux-mêmes à ceux qu’il faut aller regarder : une automatisation qui a besoin d’être surveillée pour être fiable ne le sera pas, puisque personne ne la surveillera.

Que faire au moment des pics d’activité ?

Le tester à froid. Prenez le volume du mois le plus chargé de l’an dernier, doublez-le, et demandez à chaque fournisseur ce qui se passe à ce niveau — les ruptures ne viennent presque jamais de la puissance de calcul mais des limites d’appels, de quotas d’envoi et de plafonds de messagerie. Vérifiez aussi le comportement en dépassement : refuser proprement et reprendre le lendemain est acceptable, perdre silencieusement ce qui n’a pas pu être traité ne l’est pas.

Faut-il réécrire une automatisation héritée que personne ne comprend ?

Rarement, et jamais avant de l’avoir observée. Établissez sur deux semaines ce qu’elle fait réellement et ce qui dépend d’elle en aval — un fichier qu’un comptable ouvre chaque mois, un champ qu’une autre automatisation lit. Une automatisation laide qui tourne depuis trois ans contient une règle bizarre par cas réel rencontré ; la réécriture propre les perd toutes et les redécouvre une par une, en production.

Quand faut-il en arrêter une ?

Quand la garder coûte plus qu’elle ne rapporte à partir d’aujourd’hui — le prix payé pour la construire n’entre pas dans ce calcul, il est dépensé dans tous les cas. Éteignez plutôt que de supprimer : désactivez, gardez le code et les données trois mois, prévenez les destinataires de ses envois, notez la date. L’arrêt révèle les dépendances que personne n’avait recensées mieux que n’importe quel schéma.

Où nous intervenons

Une automatisation en service dépend de services extérieurs qui changent sans vous prévenir. Le coût réel n’est pas de la construire, c’est de la garder debout.

Nous listons ces dépendances et ce qui casse si chacune bouge.
Nous réglons un seuil de volume au-delà duquel quelqu’un doit regarder.
Nous concevons aux côtés de celui qui exécute la tâche, pas de son supérieur.

Une automatisation que vous pouvez surveiller vous-même ne mérite aucun abonnement mensuel, et la plupart sont dans ce cas.

Demander un devis, après audit En parler sur WhatsApp

À voir aussi

Parlons de votre projet

Un audit gratuit, sans engagement : nous regardons votre présence en ligne et nous vous disons ce qui coince.

Demander l’audit gratuit Nous écrire