Les limites de l’automatisation dans une PME et la manière de les traiter

À partir de quand une tâche est-elle trop rare pour être automatisée ?

Toute automatisation comporte un coût de construction ainsi qu’un coût de fonctionnement, ce dernier recouvrant la surveillance, les corrections rendues nécessaires par l’évolution d’un logiciel et, le cas échéant, les appels à un modèle d’IA. Une tâche qui ne se présente que quelques fois par an ne permet pas d’amortir ces coûts, aussi fastidieuse soit-elle lorsqu’elle survient.

Le calcul s’établit en heures. Il consiste à mesurer la durée de la tâche à chaque occurrence, à la multiplier par le nombre d’occurrences annuelles, puis à comparer ce total au prix de la construction et de la supervision. Le calculateur de Nodva signale ainsi les tâches qui représentent moins de 24 heures par an, volume en deçà duquel le temps consacré à la mise en place et à la surveillance excède, en règle générale, le temps gagné. Lorsqu’une tâche reste en deçà de ce seuil, trois approches demeurent possibles :

• Regrouper les tâches voisines, car trois tâches rares portant sur les mêmes logiciels peuvent justifier ensemble une automatisation qu’aucune ne justifierait isolément.
• Préférer un modèle de document ou une liste de contrôle à une automatisation complète lorsque la tâche, bien que rare, expose à des oublis.
• Réexaminer le calcul à mesure que le volume progresse, car une tâche aujourd’hui rare peut devenir fréquente avec la croissance de l’entreprise.

Pourquoi les décisions qui engagent la responsabilité doivent-elles rester humaines ?

Un conseil délivré à un client, une signature, l’acceptation ou le refus d’un dossier engagent à la fois l’entreprise et la personne qui en décide. Une automatisation peut préparer ces décisions en rassemblant les pièces, en comparant des garanties, en rédigeant un projet de réponse ou en signalant une incohérence ; elle ne devrait pas, en revanche, les prendre à la place d’une personne habilitée.

Le droit encadre d’ailleurs cette question pour les données personnelles. L’article 22 du RGPD reconnaît en effet à toute personne le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé lorsque celle-ci produit des effets juridiques à son égard ou l’affecte de manière significative. Lorsque des exceptions s’appliquent, la personne conserve au minimum le droit d’obtenir une intervention humaine et de contester la décision.

Quel cadre les données sensibles exigent-elles ?

L’article 9 du RGPD interdit par principe le traitement de certaines catégories de données, dont celles qui concernent la santé, hors exceptions limitativement énumérées. En France, l’hébergement des données de santé relève en outre de l’article L1111-8 du code de la santé publique, qui impose le recours à un hébergeur certifié, ce que la CNIL rappelle dans ses recommandations relatives à l’informatique en nuage.

Une automatisation chargée de lire des courriels ou des pièces jointes peut rencontrer de telles données sans que leur traitement soit son objet, qu’il s’agisse d’un certificat médical joint à un dossier, d’un arrêt de travail ou d’une déclaration de sinistre corporel. Le risque tient alors autant aux informations qui transitent par le système qu’à celles qu’il conserve. Trois précautions permettent de maîtriser ce risque :

• Recenser, préalablement à la conception, les données que l’automatisation est susceptible de rencontrer, y compris de manière fortuite.
• Vérifier, pour chaque outil de la chaîne, modèle d’IA compris, le lieu où les données sont traitées et conservées.
• Étudier séparément les flux qui portent des données sensibles, lesquels peuvent requérir un hébergement certifié, une analyse d’impact ou un traitement dans un circuit distinct.

Comment procéder lorsqu’un logiciel n’offre aucun accès ?

Une automatisation lit et écrit dans vos logiciels par l’intermédiaire de leur interface de programmation, ou API. Or certains logiciels métier n’en proposent pas, ou la réservent à une option payante. La liaison demeure néanmoins souvent possible par des voies indirectes, quoique plus fragiles.

Avant tout engagement, ces voies doivent être vérifiées par un essai réel sur le logiciel concerné. Il est parfois préférable de recourir à une fonction du logiciel lui‑même, ou de demander à l’éditeur l’ouverture de son API, plutôt que de construire à côté une liaison fragile.

Pourquoi les erreurs des modèles d’IA appellent-elles une vigilance particulière ?

Un modèle de langage peut énoncer une information fausse, qu’il s’agisse d’un montant, d’une date ou d’une clause, avec la même assurance qu’une information exacte. La documentation d’Anthropic précise que les techniques destinées à réduire ces erreurs ne les éliminent pas entièrement et qu’il demeure nécessaire de valider toute information critique. Par ailleurs, un modèle interrogé deux fois sur une même demande ne fournit pas nécessairement la même réponse.

À ce risque s’ajoute celui de l’injection de prompt, qui consiste à glisser une instruction dans un courriel ou un document que le modèle sera amené à lire. L’OWASP recommande notamment, pour s’en prémunir, de limiter les droits du système au strict nécessaire et de soumettre les actions à risque à une approbation humaine. Ces recommandations se traduisent, dans la conception d’une automatisation, par trois principes :

• Recourir à un workflow à règles fixes, dépourvu d’IA, lorsque la tâche obéit à des règles stables, car il est plus prévisible et moins coûteux.
• Réserver l’IA à la lecture de contenus variables et faire vérifier ses résultats par des contrôles automatiques avant toute utilisation.
• Soumettre par défaut tout envoi destiné à l’extérieur à une validation humaine.

Comment intégrer le coût de maintenance au calcul ?

Une automatisation dépend des logiciels qu’elle relie et des modèles qu’elle sollicite. Qu’un éditeur modifie son API, qu’un accès expire ou qu’un modèle soit retiré, l’automatisation cesse de fonctionner et, en l’absence de surveillance, cet arrêt peut passer inaperçu. Anthropic annonce par exemple un préavis d’au moins 60 jours avant le retrait d’un modèle, et Claude Sonnet 4.5 sera retiré le 30 novembre 2026.

Ce coût doit donc figurer dans le calcul initial. Une automatisation reliant six logiciels instables peut exiger davantage d’entretien que le temps qu’elle libère, alors que la même tâche, ramenée aux deux logiciels principaux et complétée par une étape manuelle pour le reste, se révélera souvent plus durable.

Quelle réponse apporter à chacune de ces limites ?