IA en PME : par où commencer sans gaspiller le budget

Le vrai problème n'est pas technique

En 2026, les modèles sont largement assez bons pour la plupart des usages d'une PME. Ce qui bloque n'est presque jamais la technologie. C'est le choix du premier cas d'usage, la qualité des données, et l'absence de quelqu'un pour faire vivre le système après la mise en production.

Une PME qui démarre par le cas le plus spectaculaire — un agent conversationnel sur le site, par exemple — se retrouve six mois plus tard avec un outil que personne n'utilise, des données qu'il faut nettoyer, et une équipe qui a conclu que « l'IA, ça ne marche pas chez nous ».

Les quatre filtres avant de lancer quoi que ce soit

Avant qu'une idée devienne un projet, faites-la passer par quatre questions. Si une seule reçoit une réponse floue, le projet n'est pas mûr.

1. Valeur — qu'est-ce que ça améliore, concrètement ?

Pas « ça nous fera gagner du temps ». Combien de temps, sur quelle tâche, faite combien de fois par semaine, par qui. Si vous ne savez pas le chiffrer même grossièrement, vous ne saurez pas non plus dire si le projet a réussi.

Un exercice utile : prenez la tâche visée et comptez-la sur une semaine réelle. Pas une semaine imaginaire, une vraie, avec ses interruptions.

2. Données — existent-elles, et sont-elles propres ?

C'est le filtre qui recale le plus de projets. « Nous avons toutes les données » signifie en général qu'elles existent quelque part, réparties entre trois outils, deux tableurs et une boîte email, avec des libellés incohérents.

Une question qui tranche vite : pourriez-vous, aujourd'hui, extraire ces données et les envoyer à quelqu'un sans passer une journée à les remettre en forme ? Si non, le nettoyage fait partie du projet, et il faut le budgéter.

3. Adoption — qui l'utilise, et qui valide ?

Un système sans utilisateur nommé meurt en trois semaines. Un système sans valideur produit des erreurs qui se propagent.

Posez les deux questions à voix haute en réunion : qui, précisément, ouvrira cet outil lundi matin ? Et qui relira ce qu'il produit ? Si les réponses sont « tout le monde » et « on verra », vous avez votre réponse.

4. Maintenance — qui corrige quand ça casse ?

Un workflow n8n qui traite vos devis va casser. Pas par défaut de conception : parce qu'un outil tiers changera son API, parce qu'un champ sera renommé, parce qu'un cas non prévu se présentera. La question n'est pas si, mais qui répare.

Si la réponse est « le prestataire », vérifiez que le contrat le prévoit. Si la réponse est « personne », ne lancez pas le projet.

Par quoi commencer, concrètement

Le bon premier cas a quatre caractéristiques :

• Il est ennuyeux. Les tâches répétitives, peu valorisantes et bien cadrées sont les meilleures candidates. Elles sont faciles à mesurer et personne ne défend leur maintien.
• Il se mesure. Vous devez pouvoir dire, deux mois après, si le résultat est là.
• Il a un propriétaire. Une personne qui en bénéficie directement et qui le réclamera si ça s'arrête.
• Il échoue sans dégât. Si le système se trompe, la conséquence doit être une correction humaine, pas un client perdu.

Trois exemples qui cochent les quatre cases dans la plupart des PME : la qualification des demandes entrantes, la relance automatique des devis, et le reporting mensuel.

Ce qu'il faut refuser au début

Certains projets sont séduisants en réunion et coûteux en réalité. Au premier tour, écartez :

• Tout ce qui parle directement au client sans relecture humaine
• Tout ce qui dépend de données que vous n'avez pas encore
• Tout ce qui suppose de changer les habitudes de plus de trois personnes en même temps
• Tout ce qui existe pour « montrer qu'on fait de l'IA »

Ce dernier point mérite d'être dit clairement : un projet dont la justification principale est l'image est un projet qui ne sera pas maintenu.

Le calendrier réaliste

Pour un premier cas bien choisi, dans une PME de dix à cent personnes :

Soit entre cinq et dix semaines. Un prestataire qui vous annonce deux semaines a sauté la préparation des données, et vous le paierez plus tard.

Comment savoir que ça a marché

Fixez l'indicateur avant de commencer, et mesurez-le avant aussi. Sans mesure initiale, tout le monde aura un avis et personne n'aura de preuve.

Trois indicateurs qui fonctionnent bien :

• Temps passé sur la tâche visée, mesuré sur une semaine type
• Délai entre l'arrivée d'une demande et sa première réponse
• Nombre de fois où le système a dû être corrigé manuellement

Ce dernier est le plus révélateur. Un système corrigé dix fois par semaine ne fait pas gagner de temps : il en déplace.

En résumé

Commencez petit, sur une tâche ennuyeuse, avec un propriétaire nommé et une mesure définie à l'avance. Élargissez seulement quand le premier cas tourne sans vous depuis deux mois.

C'est moins impressionnant qu'un grand programme de transformation. C'est aussi la seule approche qui produit quelque chose.