Les limites de l'automatisation

On cite toujours les mêmes limites : l'empathie, la créativité, l'imprévu. Elles sont réelles et discutables. Il en existe une quatrième, non discutable et rarement nommée, qui arrête chaque année des projets d'automatisation par ailleurs très bien conçus.

26 août 2026 · 7 min de lecture

Les trois limites qu'on cite toujours

La première est relationnelle : un système automatisé traite mal ce qui demande de comprendre l'état d'esprit d'une personne, et un client renvoyé indéfiniment vers un canal automatique finit par partir. C'est vrai, et c'est un arbitrage plus qu'une limite — on choisit où placer le relais humain.

La deuxième est l'imprévu : un automate exécute ce qui a été anticipé, et une situation jamais rencontrée le met en défaut. Cette limite recule, parce que les systèmes récents généralisent mieux que les précédents. Elle ne disparaît pas, elle se déplace.

La troisième est la dépendance : tout automatiser, c'est faire reposer l'activité sur des systèmes dont la panne devient un arrêt complet. C'est un risque d'exploitation classique, qui se traite par des procédures de repli.

Ces trois limites ont un point commun : elles se négocient. On peut décider d'en accepter une partie, d'en compenser une autre, d'investir pour repousser la troisième. La quatrième ne se négocie pas.

Celle qu'on oublie : le dernier mètre

Appelons dernier mètre le point où un processus entièrement logiciel doit produire un effet sur un objet, un lieu ou un document physique. Ouvrir, déplacer, brancher, photographier, réceptionner, constater sur place, signer un papier.

Ce point n'est pas une difficulté de plus dans une liste : il est d'une autre nature. Les trois limites précédentes portent sur la qualité de ce que le système produit. Celle-ci porte sur la possibilité même d'agir. Aucun modèle plus grand, aucune intégration supplémentaire, aucun budget de calcul ne la franchit, parce qu'il ne s'agit pas de savoir mais d'être quelque part.

Le terme est emprunté au vocabulaire de la logistique, où le dernier kilomètre désigne le segment final d'une livraison, le plus coûteux de toute la chaîne. La parenté est réelle : dans les deux cas, c'est le segment le plus court qui concentre la difficulté, parce que c'est le seul qui touche le monde.

Une précision utile, parce que la confusion est fréquente : le dernier mètre n'est pas la partie « difficile » d'un projet d'automatisation. Il en est souvent la partie la plus triviale à décrire — prendre une photo, ouvrir une porte. Ce qui le rend coûteux n'est pas sa complexité, c'est qu'il est hors d'atteinte. On peut le spécifier en une phrase et ne jamais pouvoir l'exécuter, ce qui est exactement l'inverse du reste du travail d'ingénierie.

Pourquoi il coûte plus cher qu'il n'en a l'air

Le dernier mètre est rarement mesuré, parce qu'il est absorbé par des gens qui le traitent en plus de leur travail. Il coûte pourtant sur cinq postes distincts, et ces coûts se cumulent.

Le délai : le processus s'arrête le temps qu'une personne disponible soit trouvée, ce qui se compte en heures ou en jours, jamais en secondes.
La traçabilité : ce qui est fait hors du système n'est documenté nulle part, donc ni auditable, ni améliorable, ni facturable au bon endroit.
Le plafond de charge : l'automatisation cesse de passer à l'échelle au moment exact où elle réussit, puisque la reprise manuelle croît avec le volume.
La qualité : une consigne transmise oralement ou par message produit une exécution variable, alors que le reste de la chaîne est déterministe.
Le coût d'attention : chaque reprise interrompt quelqu'un, et le coût d'une interruption dépasse largement la durée de la tâche reprise.

Quatre contournements, et le plafond de chacun

Les organisations qui rencontrent ce point emploient à peu près toujours l'une de ces quatre stratégies. Chacune fonctionne, et chacune a un plafond identifiable.

Restreindre le périmètre aux étapes purement logicielles est robuste et honnête, mais renonce aux processus qui touchent le réel — souvent ceux dont la valeur est la plus élevée, précisément parce que personne ne les a automatisés.

Rendre la main à un opérateur interne fonctionne bien à petit volume. Le plafond est celui de l'effectif : l'automatisation devient une machine à produire du travail manuel pour ses propres équipes.

Sous-traiter au cas par cas à un prestataire local marche une fois, et ne s'industrialise pas : il faut chercher, négocier, briefer et payer à chaque occurrence, ce qui coûte plus cher que la tâche.

Investir dans une machine dédiée est rentable quand la tâche se répète à l'identique dans un espace maîtrisé. Sur des interventions uniques dans des lieux ordinaires, l'amortissement ne se fait jamais.

Le test à faire sur votre propre processus

Avant de choisir une stratégie, il faut savoir où se trouve exactement le dernier mètre, et il est presque toujours ailleurs que là où on le croit. Le diagnostic tient en cinq questions, à poser sur un processus réel plutôt que sur son schéma.

À quelle étape précise l'exécution automatique s'arrête-t-elle, et depuis combien de temps s'y arrête-t-elle sans que personne ne l'ait consigné ?
Qui reprend, comment est-il prévenu, et cette personne était-elle censée faire cela ?
Combien de temps s'écoule entre l'arrêt et la reprise, mesuré et non estimé ?
Que devient la preuve de ce qui a été fait — existe-t-elle, et le système la récupère-t-il ?
Que se passerait-il si le volume était multiplié : la reprise suit-elle, ou devient-elle le goulot ?

Traiter le dernier mètre comme une dépendance

Le changement de regard utile consiste à cesser de voir cette étape comme une exception à gérer, et à la traiter comme ce qu'elle est : une dépendance externe du processus, au même titre qu'une interface tierce ou qu'un service de paiement.

Une dépendance a un contrat, un délai, un coût, un mode de défaillance et une trace. Modélisée ainsi, l'étape physique cesse d'être un trou dans le schéma : elle devient un appel, avec des paramètres en entrée — objectif, lieu, fenêtre, budget — et un résultat vérifiable en sortie.

C'est ce qui permet enfin de la mesurer, donc de l'améliorer, et de savoir combien elle coûte réellement — ce que la reprise manuelle informelle ne permet jamais, puisqu'elle n'apparaît dans aucun tableau.

Ce que change le fait de le mesurer

Une organisation qui commence à consigner ses reprises manuelles découvre presque toujours la même chose : elles sont plus nombreuses que prévu, concentrées sur un petit nombre d'étapes, et supportées par un petit nombre de personnes. Ces trois faits sont invisibles tant que rien n'est compté, parce que chaque reprise prise isolément paraît négligeable.

La mesure change aussi la nature de la décision. Tant que l'étape physique est traitée comme une exception, la seule question posée est « qui peut s'en occuper ». Une fois qu'elle a un coût et un délai chiffrés, la question devient « ce coût justifie-t-il de l'externaliser, de l'outiller, ou de renoncer à cette partie du processus » — et cette question-là se tranche.

Ce qui existe aujourd'hui, et ce qui n'existe pas

4bl1ty est construit sur cette idée : un donneur d'ordre, humain ou logiciel, publie une mission décrivant une étape physique, une personne proche l'exécute, le paiement est placé sous séquestre avant le début et libéré à la validation de la preuve convenue.

Ce qui existe : le mécanisme de séquestre, la vérification d'identité opérée par le prestataire de paiement, et une surface d'intégration destinée aux agents, dont la documentation ne décrit que les outils réellement exposés.

Ce qui n'existe pas encore : l'ouverture au public. Les missions ne sont pas ouvertes, et nous n'affichons aucun volume, aucun délai moyen, aucun taux de réussite — ces chiffres seront publiés quand ils auront une réalité derrière eux, et pas avant.

Termes employés

Chaque terme renvoie à sa définition ; l'ensemble forme le glossaire de la couche physique.

Dernier mètre: Le point où un processus entièrement logiciel doit produire un effet sur un objet, un lieu ou un document, et s'arrête faute de pouvoir agir lui-même.
Couche physique: L'ensemble des actions qu'un système logiciel ne peut pas exécuter lui-même parce qu'elles exigent une présence dans le monde réel, et le dispositif qui permet de les déléguer à des personnes.
Agent IA: Un système bâti sur un modèle de langage qui poursuit un objectif en enchaînant des décisions et des appels d'outils, sans qu'un humain valide chaque étape.
Appel d'outil: L'opération par laquelle un modèle de langage déclenche une action extérieure en produisant un appel structuré, dont il reçoit ensuite le résultat pour poursuivre son raisonnement.
Preuve d'exécution: L'élément observable qui atteste qu'une mission a bien été accomplie, défini avec la mission elle-même et non après coup.
Humain dans la boucle: Un montage où une personne intervient à un point défini d'un processus automatisé, pour décider, valider ou exécuter ce que le système ne peut pas assumer seul.