Automatiser, oui. Mais pas comme ça.

Un quart des TPE-PME françaises déclarent aujourd’hui utiliser une solution d’intelligence artificielle. C’est deux fois plus qu’il y a un an. Sur le papier, la bascule est spectaculaire. Sur le terrain, elle l’est beaucoup moins : parmi ces mêmes entreprises, seules 5 % automatisent réellement une tâche du quotidien. Pas 5 % de plus. 5 % tout court.

Entre les deux chiffres, il y a tout ce qui sépare “avoir essayé ChatGPT” de “avoir un processus qui tourne sans qu’on y pense”.

Dans le premier cas, un salarié ou un dirigeant ouvre un outil ponctuellement, pour rédiger un mail ou reformuler une annonce — le gain de temps existe, mais reste occasionnel, limité à l’instant où quelqu’un pense à s’en servir.

Dans le second, une tâche entière a été retirée du quotidien de quelqu’un : la facture part sans que personne ne clique sur “envoyer”, la relance se déclenche sans qu’on ait eu à y penser, la donnée se met à jour sans être ressaisie. Et c’est là que tout se joue : une relance envoyée systématiquement à J+7 puis J+15 fait gagner du temps, mais surtout elle fait gagner des jours de trésorerie — une facture qui reste en attente d’un “on va relancer” a moins de chances d’être payée à temps qu’une facture réellement relancée, sans que personne n’ait besoin de s’en préoccuper. Aucune IA n’est d’ailleurs nécessaire pour une telle automatisation : c’est une question de systématisation, pas d’intelligence artificielle.

Le grand écart

Le Baromètre France Num 2025 fait état d’un usage croissant de l’IA dans les TPE-PME, qui double en un an, passant de 13 à 26 %. Mais quand on regarde comment ces entreprises utilisent concrètement l’IA, l’écart entre usage de l’IA et automatisation apparaît alors nettement.

L’automatisation de tâches – un processus qui s’exécute seul, sans intervention manuelle – ne concerne que 5 % de ces entreprises, en hausse de seulement 2 points sur un an.

Ce n’est pas un problème de technologie. Les outils existent, ils sont accessibles, souvent peu coûteux. C’est un problème de prise de décision. Une entreprise sur quatre a testé l’IA. Une sur vingt en a fait un outil de production. Les autres sont restées en retrait – convaincues que quelque chose se joue, mais sans avoir transformé cette conviction en processus.

Certains ont amorcé, timidement, un passage à l’IA.

C’est le dirigeant qui a demandé à ChatGPT de rédiger une offre d’emploi la semaine dernière, mais qui ressaisit encore à la main les mêmes informations dans trois outils différents chaque fois qu’un client passe commande.

C’est l’équipe commerciale qui utilise un assistant IA pour reformuler ses emails de prospection, mais qui note toujours ses relances sur un post-it ou dans un tableau Excel.

L’usage ponctuel d’un outil intelligent ne dit rien de la capacité d’une entreprise à automatiser un processus – ce sont deux compétences différentes, et la seconde ne se résume pas à un abonnement mensuel.

Cet écart n’est pas propre à l’IA. Il rejoint un constat plus large et plus ancien sur la transformation digitale des PME françaises : depuis 2017, la part de PME et ETI ayant entamé leur transformation numérique n’a progressé que de 72 % à 76 %. Neuf ans pour quatre points. À ce rythme, “amorcer” est en train de devenir un état permanent plus qu’une étape.

Cette lenteur s’explique en partie par un chaînon qu’on saute trop souvent dans le débat public : entre le papier et l’automatisation, il y a plusieurs étapes, pas une seule bascule. Une entreprise dont les fiches clients tiennent encore sur des classeurs, dont la facturation se fait à la main et dont aucune donnée n’est structurée quelque part n’a pas de raison de se demander quel outil d’IA installer — sa vraie première question est plus basique : où est l’information, et sous quelle forme ? Avoir un site vitrine ou un logiciel de comptabilité ne dit d’ailleurs rien de ce niveau de maturité : on peut très bien afficher une belle vitrine numérique tout en pilotant sa relation client sur papier en coulisses. Automatiser suppose une donnée déjà accessible et fiable quelque part ; sans cette base, l’automatisation n’est simplement pas la bonne question à se poser — encore moins l’IA, qui arrive plus loin sur ce chemin.

Ce que coûte une approche empirique

L’immobilisme a un coût, et il est chiffrable.

Un tiers des TPE-PME gère encore ses factures manuellement ou avec des outils non spécialisés. Résultat : 85 % des entreprises françaises ont subi des retards de paiement en 2024, avec un retard moyen de 13,6 jours par facture – en hausse par rapport à l’année précédente. Ce n’est pas une fatalité conjoncturelle, c’est en bonne partie une conséquence directe de processus de relance qui reposent sur la mémoire ou la bonne volonté de quelqu’un, plutôt que sur un système qui déclenche une relance au bon moment, systématiquement.

À l’autre bout de la chaîne, 43 % des PME et ETI françaises n’utilisent toujours pas l’analyse de données pour piloter leur activité. Pas de tableau de bord, pas d’indicateur suivi dans le temps – des décisions prises à l’instinct, dans un contexte où la donnée existe déjà, quelque part, dans un tableur ou un logiciel métier, mais où personne ne l’a jamais reliée à rien.

Le bricolage ne se voit pas sur une facture. Il se voit dans le temps perdu à ressaisir une information trois fois, dans les relances qu’on oublie d’envoyer, dans les décisions prises sans les chiffres qui auraient dû les éclairer. C’est un coût diffus, mais réel – et cumulatif.

Prenons un exemple simple, presque banal : une entreprise de 8 salariés qui facture une trentaine de clients par mois. Si chaque relance de facture impayée demande dix minutes – retrouver le dossier, vérifier l’échéance, rédiger le mail – et qu’un tiers des factures nécessite une relance, cela représente un peu plus d’une heure par mois. Peu de choses, en apparence. Mais dans les faits, cette heure n’est jamais prise : elle est reportée, oubliée entre deux urgences, et c’est précisément ce report qui nourrit les 13,6 jours de retard moyen observés à l’échelle nationale. Un processus automatisé ne fait pas disparaître le travail par magie ; il l’exécute au moment où il doit l’être, sans dépendre de la disponibilité de quelqu’un ce jour-là. Et il envoie un signal fort : le retard n’est pas - ou n’est plus - une option.

Le vrai verrou n’est pas technique

Les outils ne sont pas en cause — on vient de le voir avec la relance de facture, qui ne demande ni IA ni prouesse technique. Le vrai verrou est ailleurs, et les chiffres de l’étude Bpifrance Le Lab, menée en 2025 auprès de plus de 1 200 dirigeants de PME et ETI, donnent une indication assez nette de où : 73 % des projets liés à l’IA ou à l’automatisation sont impulsés directement par le dirigeant. Pas par une DSI, pas par un chef de projet dédié – par le patron lui-même, en plus du reste. Et seulement 43 % de ces mêmes dirigeants ont formalisé une véritable stratégie derrière cette impulsion.

Ce déséquilibre est la clé de beaucoup d’échecs silencieux, et il se présente essentiellement sous plusieurs formes .

• Un dirigeant convaincu qui se lance seul, sans méthode ni accompagnement technique. Il choisit un outil sur la base d’une recommandation entendue en réseau d’affaires, ou en s’aidant d’un chatbot IA, le configure entre deux rendez-vous, et obtient souvent un résultat en demi-teinte – un outil qu’on utilise à l’occasion mais qui n’emporte pas l’adhésion de l’équipe, ou qui n’est utile que dans certains cas, un tableau croisé dynamique qui complète ou remplace un autre tableau croisé dynamique. La conviction était réelle, mais elle n’a jamais été traduite en un cadrage suffisamment précis pour que le projet tienne.
• Un projet confié à un prestataire compétent, mais dont le dirigeant se désengage une fois le brief initial donné. L’outil est livré, techniquement solide, mais personne en interne ne s’en approprie l’usage, personne ne remonte les cas particuliers qu’il n’a pas prévus, personne ne pousse à l’ajuster quand un processus métier change. Sans ce relais, même le système le mieux conçu ne sert à rien : au bout de quelques mois, et parfois même de quelques semaines, on revient aux vieilles habitudes en parallèle, et l’outil devient une dépense qu’on n’utilise plus qu’à moitié.

Il y a un troisième point commun aux échecs, moins souvent nommé mais tout aussi déterminant : l’outil réglait un problème vu par le dirigeant, pas un problème vécu par ceux qui l’utilisent au quotidien. C’est la différence entre automatiser une tâche que l’équipe commerciale râle de devoir refaire chaque semaine — et qu’elle adopte donc sans qu’on ait besoin de la convaincre — et automatiser quelque chose que personne n’avait identifié comme un problème, imposé d’en haut sans qu’aucune friction réelle n’en justifie l’usage aux yeux de ceux qui doivent s’en servir. Un outil peut être irréprochable techniquement et rester lettre morte simplement parce qu’il ne soulage personne concrètement : sans point de douleur reconnu par les utilisateurs eux-mêmes, il n’y a pas de raison spontanée de changer une habitude, aussi inefficace soit-elle.

Ce sont les trois mêmes ingrédients qui reviennent dans presque tous les projets d’automatisation réussis observés sur le terrain : un dirigeant qui comprend ce qu’il automatise et pourquoi, et qui reste impliqué après la mise en service ; un prestataire qui a la rigueur technique pour transformer cette conviction en un système qui tient dans la durée ; et une tâche qui correspond à une friction réellement ressentie par ceux qui devront s’en servir, pas seulement à une idée séduisante sur le papier. Retirez l’un des trois, et le projet reste fragile.

Bref aperçu des familles d’outils d’automatisation

Sans entrer dans un comparatif outil par outil, il est utile de savoir que l’automatisation ne se joue pas sur un seul registre. Trois grandes familles coexistent, avec des utilisations type différentes :

Le no-code

Les outils tels que Zapier ou Make sont très rapides à mettre en place, adaptés aux connexions simples entre outils déjà en place (un formulaire qui alimente un CRM, par exemple). Leur limite arrive vite, dès que la logique métier se complexifie ou que le volume grimpe.

Le low-code et les orchestrateurs visuels

Les plateformes telles que n8n (auto-hébergeable ou cloud) ou OttoKit (cloud, natif WordPress) offrent plus de contrôle et permettent de gérer des scénarios plus riches. En contrepartie, la courbe d’apprentissage est plus raide et la maintenance requiert des compétences techniques, en interne ou chez le prestataire.

Le développement sur-mesure

Cette approche est pertinente quand le volume, la criticité, ou la complexité de la logique sont au-delà de ce que les outils précités permettent d’obtenir sans perdre en fiabilité. Le coût peut être plus élevé, mais l’outil sera plus robuste et correspondra exactement au besoin de l’entreprise.

Aucune de ces trois familles n’est “meilleure” dans l’absolu. Le bon choix dépend du volume à traiter, de la criticité de la tâche, et de la capacité de l’entreprise à maintenir la solution dans le temps – pas d’une mode ou d’un nom qui revient dans toutes les conversations.

Ce qui fait vraiment basculer un projet du bon côté

Trois réflexes reviennent systématiquement dans les projets d’automatisation qui tiennent dans la durée, à l’inverse des 95 % de TPE-PME qui n’ont encore rien automatisé de concret :

Structurer avant de lancer un projet

Identifier précisément la tâche répétitive, son volume, sa fréquence, et ce qu’elle coûte réellement en temps et en pénibilité – avant de choisir un outil. La pénibilité mérite d’être prise au sérieux autant que le temps : une relance de facture qui doit être faite avant une certaine heure, une tâche qui nécessite une habilitation que tout le monde n’a pas, ou qui oblige à se connecter sur un poste particulier en ressaisissant toute une série d’identifiants – ce sont des frictions qui pèsent sur le quotidien sans forcément apparaître dans un calcul de temps passé. Cela suppose de répondre à des questions simples mais rarement posées : combien de fois cette tâche revient-elle par semaine ou par mois ? Qui s’en occupe aujourd’hui, et que ferait-on du temps libéré ? Est-ce une tâche que cette personne mentionne spontanément comme pénible ou source d’erreurs, ou une friction que seul le dirigeant perçoit de l’extérieur ? Que se passe-t-il si le processus automatisé échoue une fois sur cent – qui s’en aperçoit, et comment ? Beaucoup de projets partent de l’outil (“on m’a parlé de tel logiciel”) plutôt que du besoin, et faire l’impasse sur le cadrage est souvent le premier signe d’un projet qui ne durera pas.

Impliquer le dirigeant dans la durée, pas seulement au lancement

Les 73 % de projets initiés par le dirigeant sont un bon point de départ, mais un point de départ seulement. Le risque est que cette implication s’arrête une fois l’outil configuré – que le dirigeant considère le sujet comme “réglé” dès la mise en production. Or un processus automatisé a besoin d’être suivi dans le temps : ajusté quand le volume augmente, corrigé quand une règle métier change, remis en question si les résultats qu’il produit ne sont plus adaptés. Cette implication continue ne demande pas beaucoup de temps – un point rapide chaque mois suffit souvent – mais elle doit être prévue dès le départ, plutôt que laissée au hasard des priorités du moment.

Choisir le bon outil, pas le plus impressionnant

Un outil no-code bien calibré sur un besoin simple vaut mieux qu’une solution sur-mesure surdimensionnée qu’on ne saura pas maintenir une fois le prestataire parti. Et inversement, forcer un processus critique à volume élevé dans un outil qui n’est pas fait pour ça – parce qu’il a l’air simple et rapide à mettre en place – finit presque toujours par coûter plus cher que prévu, entre les correctifs, les relances manuelles et la migration qu’il faudra faire un jour vers une solution plus robuste. Le bon outil est rarement celui dont on parle le plus dans les conférences ; c’est celui qui correspond exactement au problème posé.

Une fracture qui se referme par la méthode, pas par la technologie

L’automatisation n’est pas un problème de retard technologique en France – les outils sont là, à tous les niveaux de budget et de complexité, du no-code accessible en quelques heures au développement sur-mesure. C’est un problème de méthode : peu d’entreprises cadrent correctement avant de se lancer, moins encore maintiennent l’implication nécessaire une fois l’outil en place, et l’écart entre 26 % qui testent l’IA et 5 % qui automatisent vraiment au moins une tâche en est la preuve la plus nette.

Ce principe – partir du problème plutôt que de l’outil du moment – dépasse largement l’automatisation. On le retrouve, formulé presque à l’identique, dans l’article sur la pertinence d’un blog d’entreprise : ce qui vieillit mal, ce n’est jamais le besoin métier, c’est la technologie qu’on a mise en avant pour y répondre.

Combler cet écart ne demande pas nécessairement un grand projet. Il demande surtout de se lancer : transformer un usage ponctuel et une impression diffuse en un processus cadré, suivi, et ajusté dans la durée.

Un bon point de départ, avant de penser outil : listez les tâches que vous ou votre équipe répétez le plus souvent – une relance, une saisie, un export… C’est presque toujours par là que commence un projet d’automatisation réussi — plutôt que de laisser l’attentisme continuer à se payer en jours de trésorerie perdus, en heures ressaisies, et en décisions prises sans les chiffres qui auraient dû les éclairer, mois après mois, comme c’est le cas pour la grande majorité des TPE-PME françaises aujourd’hui.