En quatre semaines, j’ai beaucoup parlé d’intelligence artificielle avec mes clients. Point de rentrée oblige, nous avons cherché comment chacun pouvait en tirer parti dans son activité.
Même technologie, situations radicalement différentes.
Certains veulent automatiser vite et fort. D’autres attendent un outil prêt à l’emploi. Certains ont déjà construit des systèmes avancés. D’autres n’ont ni le temps, ni la marge financière, ni l’envie de prendre des risques.
Au-delà des écarts de maturité numérique, j’ai surtout retrouvé une confusion : parce que l’IA permet désormais de générer du code, des automatisations ou des interfaces, nous pourrions tous devenir constructeurs de logiciels.
Ce n’est pas si simple. Démocratiser la génération d’outils ne démocratise ni leur conception, ni leur intégration, ni leur maintenance.
Six façons d’aborder l’IA en PME
Les situations suivantes sont réelles, mais certains éléments ont été modifiés ou combinés afin de préserver la confidentialité des entreprises concernées.
Client A : « Je veux remplacer une partie du travail par l’IA »
L’entreprise dispose d’une équipe structurée, de processus identifiés et de plusieurs années de données. Son dirigeant veut s’appuyer sur ce patrimoine pour répondre plus vite aux clients et réduire les coûts.
Il assume une logique offensive : si ses concurrents automatisent avant lui, il craint de perdre en compétitivité. Il est curieux, volontaire et prêt à lancer plusieurs chantiers.
Son avantage est clair : il peut agir vite. Son risque l’est aussi : confondre réduction d’effectif et amélioration du processus. Automatiser une tâche ne fait pas disparaître les contrôles, les exceptions, la responsabilité ni la maintenance. La première étape devrait donc être de cartographier précisément le travail avant de décider ce qui peut être automatisé, assisté ou doit rester humain.
Client B : « J’utilise déjà l’IA partout »
Face à une forte croissance, ce client cherche à réduire le temps consacré aux tâches répétitives. Il multiplie les abonnements et expérimente sans attendre.
Il a même confié à l’IA la création et l’envoi de factures. Le système lui a fait gagner du temps, mais l’IA a aussi inventé des prestations et des tarifs. Quelques erreurs qu’il a fallu retrouver puis corriger.
Sa capacité d’expérimentation est précieuse. Mais une automatisation qui touche à la facturation ne peut pas fonctionner comme un simple brouillon généré dans un chatbot. Il faut séparer la production, la vérification et l’envoi, définir les règles métier et conserver une trace des contrôles. La prochaine étape n’est pas d’ajouter un nouvel outil : c’est de fiabiliser ceux qui existent déjà.
Client C : « Pourquoi les autres n’avancent-ils pas plus vite ? »
Ce client technophile dispose de beaucoup de données, historiquement de qualité inégale. L’IA permet désormais de les enrichir et de mieux les exploiter. Les premiers résultats ouvrent de vraies perspectives.
Mais cette avance crée une nouvelle fragilité. Une grande partie du système repose sur un collaborateur qui comprend les données, les outils et les enchaînements techniques. Que se passe-t-il s’il quitte l’entreprise ? Qui possède les comptes ? Où sont documentées les règles ? Qui peut reprendre le système lorsqu’un fournisseur change son API ou ses tarifs ?
L’enjeu n’est plus seulement d’innover. Il faut rendre l’innovation transmissible : documenter, répartir les accès, organiser les sauvegardes et supprimer les dépendances critiques à une seule personne.
Client D : « Je veux faire bien du premier coup »
Le dirigeant est volontaire, mais son entreprise dispose de peu de marge de manœuvre. Le marché est tendu et chaque investissement doit produire un résultat. Dans ce contexte, laisser les autres essuyer les plâtres paraît raisonnable.
Le risque serait pourtant d’attendre une solution parfaite qui n’existera jamais. À l’inverse, lui conseiller un grand programme de transformation serait irresponsable.
La bonne réponse est un test limité : un seul processus, un coût plafonné, une intervention humaine possible à tout moment et des critères de réussite définis avant le lancement. Il ne s’agit pas de supprimer le risque, mais de le rendre supportable et réversible.
Client E : « J’ai besoin d’être mis sur de bons rails »
Ce client a des idées, une connaissance fine de son métier et une certaine revanche à prendre sur une informatique qui l’a longtemps empêché d’avancer. L’IA lui rend accessibles des projets qu’il n’aurait pas envisagés auparavant.
Son besoin principal n’est pas qu’un prestataire fasse tout à sa place. Il a besoin d’un cadre pour distinguer une bonne idée d’un projet utile, choisir un premier périmètre et éviter de commencer par l’outil.
L’accompagnement ne garantit pas la réussite. Il permet surtout de clarifier le besoin, les risques, les responsabilités et les critères de décision avant d’engager du temps et de l’argent.
Client F : « Je veux acheter un service IA prêt à l’emploi »
Cette entreprise a déjà de nombreux chantiers en retard. L’IA est jugée importante, mais personne ne souhaite ajouter un nouveau projet complexe à la liste. Le dirigeant ne veut ni apprendre à construire des agents, ni gérer un assemblage de services techniques. Il veut un résultat.
C’est une attente parfaitement rationnelle. Toutes les entreprises n’ont pas vocation à développer leurs propres outils.
Il faut alors commencer par une tâche chronophage, stable et peu risquée, puis livrer un service intégré aux habitudes existantes. Pas une démonstration spectaculaire. Pas un tableau de bord supplémentaire. Un fonctionnement plus simple, avec un responsable identifié et une solution de repli en cas de panne.
Générer n’est pas construire
Ces six profils n’ont ni les mêmes moyens, ni les mêmes ambitions. Mais ils rencontrent tous, à un moment ou à un autre, la différence entre une démonstration convaincante et un outil réellement exploitable.
Un chatbot peut produire une formule Excel, un script ou une interface en quelques secondes. Le vibe coding permet de créer un prototype en décrivant le résultat attendu en langage naturel. C’est impressionnant, oui, et c’est souvent utile.
Mais le prototype ne connaît pas spontanément les exceptions métier. Il ne décide pas qui peut consulter quelles données. Il ne prévoit pas le départ de son créateur, la modification d’une API, l’augmentation des coûts, les erreurs silencieuses ou la procédure de secours.
Un rapport préliminaire publié en 2025 par le projet NANDA du MIT a popularisé un chiffre spectaculaire : 95 % des organisations étudiées n’auraient obtenu aucun retour financier mesurable de leurs initiatives d’IA générative. Cela ne signifie pas que 95 % de tous les projets d’IA échouent. Le périmètre et le caractère préliminaire du rapport imposent de rester prudent. Il montre néanmoins l’écart entre la multiplication des pilotes et leur impact économique mesurable.
L’enquête mondiale publiée par McKinsey en mars 2025 aboutit à un constat comparable. Plus des trois quarts des répondants déclaraient que leur organisation utilisait l’IA dans au moins une fonction. Pourtant, plus de 80 % ne constataient pas d’effet tangible de l’IA générative sur le résultat opérationnel à l’échelle de l’entreprise. Seuls 21 % des répondants utilisant l’IA générative indiquaient avoir profondément repensé au moins certains processus de travail.
Le problème n’est donc pas seulement l’accès aux modèles. Il se situe dans le passage de l’usage individuel à la transformation d’un processus collectif.
On est loin de la révolution promise.
Et puis, en vérité, certains collaborateurs voient bien que la machine va faire disparaître leur poste et n’ont aucun intérêt immédiat à nourrir la bête…
Les compétences que l’IA ne remplace pas
Construire une automatisation ou un logiciel utile nécessite toujours des compétences transversales et une culture technique minimale. Non pour tout développer soi-même, mais pour poser les bonnes questions et savoir quand faire intervenir un spécialiste.
Devenir l’architecte de ses propres solutions numériques, tout en sachant reconnaître les situations nécessitant l’intervention d’un spécialiste, n’est pas à la portée de tout le monde.
| Compétence | Ce qu’il faut savoir faire |
|---|---|
| Analyse des processus | Cartographier le fonctionnement existant, les tâches répétitives, les exceptions et les points de friction |
| Formalisation du besoin | Transformer une idée vague en objectifs, règles métier, fonctionnalités et critères de réussite explicites. |
| Pensée systémique | Comprendre les interactions entre les personnes, les données, les outils et les processus, puis anticiper les effets en cascade. |
| Décomposition des problèmes | Découper un projet complexe en étapes simples, indépendantes et vérifiables. |
| Culture des données | Comprendre les structures de données, leur qualité, leur circulation et leurs usages. |
| Conception fonctionnelle (UX) | Imaginer un outil compréhensible et adapté à ses utilisateurs, sans multiplier les fonctionnalités inutiles. |
| Pilotage de projet agile | Prioriser, prototyper, tester, recueillir les retours et améliorer sans engager immédiatement un déploiement général. |
| Évaluation économique | Estimer les gains, les coûts de développement, les coûts récurrents, la maintenance et le retour sur investissement. |
| Gestion des risques | Intégrer la confidentialité, la sécurité, la conformité, les sauvegardes et la continuité d’activité. |
| Documentation et transmission | Rendre les outils compréhensibles, maintenables et transmissibles à un collègue ou à un prestataire. |
L’IA peut aider dans chacune de ces activités. Elle ne supprime pas la nécessité de les mener.
Cinq questions avant de construire
Avant de générer la première ligne de code ou de connecter deux outils, voici cinq questions à vous poser :
- Quel processus voulons-nous réellement modifier ? Une tâche isolée n’est pas toujours le bon périmètre.
- Quel résultat mesurable attendons-nous ? Temps économisé, erreurs évitées, délai réduit, chiffre d’affaires supplémentaire : il faut choisir.
- Quelles erreurs pouvons-nous accepter ? Une faute dans un brouillon et un tarif inventé sur une facture n’ont pas les mêmes conséquences.
- Qui sera responsable du fonctionnement ? Il faut un propriétaire du processus, pas seulement le créateur du prototype.
- Que se passera-t-il en cas de panne ou de départ ? Documentation, accès, sauvegardes et solution de repli doivent exister avant que l’outil devienne critique.
Permettre à chacun de générer un outil ne transforme pas automatiquement l’entreprise. L’enjeu demeure la transformation des processus et l’intégration dans les pratiques ordinaires : messagerie, bureautique, gestion commerciale, production ou relation client.
L’IA abaisse fortement la barrière technique. Elle ne supprime ni le besoin de discernement, ni la responsabilité, ni la conduite du changement.
Le bon premier projet n’est donc pas le plus spectaculaire. C’est celui qui répond à un problème réel, reste réversible, produit un résultat mesurable et peut survivre à la personne qui l’a construit.