Les projets IA n'échouent pas parce que la technologie est trop complexe. Ils échouent parce que le projet est mal configuré dès le départ. Ce sont des erreurs de méthode — toutes évitables.
Ces phrases sonnent comme le début d'un projet. Ce ne sont pas des projets — ce sont des intentions. Un projet IA qui démarre sans problème mesurable n'a pas de ligne d'arrivée. Personne ne sait ce que « ça marche » veut dire. Le projet dérive. Six mois plus tard, la question « mais est-ce que ça nous a apporté quelque chose ? » n'a pas de réponse.
L'IA crée une pression sociale à « ne pas rater le train ». Des concurrents l'utilisent. La presse en parle. Des commerciaux SaaS promettent une transformation en 30 jours. Dans cet environnement, décider de « faire de l'IA » est plus facile que de prendre 2 heures pour définir précisément ce qu'on veut résoudre.
Une seule. Elle doit contenir : le problème, le périmètre, et un indicateur chiffré.
« On veut améliorer notre service client. »
« Réduire le temps de traitement des demandes FAQ entrantes sur WhatsApp de 4 h à 30 min/semaine, sans recruter. »
Votre indicateur n'a pas besoin d'être parfait. Il doit être mesurable. Si vous ne pouvez pas mesurer l'amélioration, vous ne pouvez pas savoir si le projet a réussi — et vous ne pourrez pas le défendre quand les premières difficultés apparaissent.
30 minutes avec ChatGPT à lui faire rédiger des fiches produit. Résultat impressionnant. Vous décidez que « l'IA va gérer la rédaction ». Vous communiquez en interne. Trois semaines plus tard, le projet est au point mort parce que personne n'a défini comment les données arrivent dans le prompt, comment les sorties sont relues, où elles sont stockées, qui valide avant publication, et comment corriger quand le modèle se trompe.
La démo est magique. Elle montre le cas idéal, avec des données propres, sans contrainte opérationnelle. Le passage au déploiement exige de traiter exactement ce que la démo ignorait : les cas limites, la gestion des erreurs, le monitoring, la formation, le rollback.
Le gap entre « ça marche en démo » et « c'est en production fiable » représente entre 60 et 80 % du travail réel sur un projet IA moyen.
Si une de ces questions est sans réponse, le projet n'est pas prêt à passer en production. Ce n'est pas un blocage — c'est un travail à faire avant de déployer.
Le projet démarre avec cette contrainte imposée. Plus tard, on découvre que le volume de requêtes rend le coût prohibitif, que les données doivent rester en Europe, ou que le modèle ne performe pas bien sur le type spécifique de document à traiter. Le choix du modèle avant l'analyse de l'usage crée des contraintes d'architecture dès le départ. Changer ensuite est possible, mais coûteux.
Les noms de modèles sont devenus des raccourcis dans la conversation publique. « Tu utilises GPT-4 ? » est une question courante, comme « tu utilises Excel ? » — sans considération pour ce qu'on y fait. La marque prime sur le choix technique.
Extraction de données structurées depuis des PDF ? Rédaction en français avec ton spécifique ? Classification d'emails ? Chaque tâche a ses exigences.
Résidence des données, coût maximum par requête, latence acceptable, volume mensuel.
Sur 20 à 50 exemples de votre vrai flux — pas sur des données synthétiques.
Le moins cher qui satisfait votre critère de qualité. Pas le plus performant en général.
Cette séquence prend quelques heures de plus au départ. Elle évite des semaines de refactoring plus tard.
Vous indexez tout ce que vous trouvez : des procédures de 2018 qui ont changé, des fichiers version finale v3 corrigée FINAL.docx, des emails transférés 10 fois, des scans PDF illisibles. L'assistant répond avec confiance en citant des procédures obsolètes, mélange des informations contradictoires. Le projet est abandonné avec un jugement définitif : « l'IA, ça ne marche pas pour nous ».
« On a des données » est souvent vrai. « Nos données sont exploitables pour un système IA » est souvent faux. Les documents internes accumulent des années d'entropie : doublons, versions multiples sans versioning clair, contenu obsolète jamais supprimé. Un humain navigue intuitivement dans ce chaos. Un modèle prend tout au pied de la lettre.
Lister toutes les sources documentaires. À jour ? Structurée ? Qui en est responsable ?
Supprimer doublons, versions obsolètes, fichiers sans propriétaire. Mieux vaut 200 docs propres que 2 000 douteux.
Titre clair, date de mise à jour, périmètre. Ces métadonnées améliorent la pertinence de la récupération.
Faire valider les documents clés par leur propriétaire métier avant intégration.
Ce travail est ingrat. Il est aussi la condition principale du succès d'un assistant RAG. Les équipes qui le sautent le font à chaque fois — une seule fois.
Le prestataire configure le système, forme l'équipe, livre la documentation. Puis il part. Deux mois plus tard, le modèle produit des réponses décalées parce que personne n'a mis à jour les données. Le chatbot répond encore avec les tarifs de l'an dernier. L'assistant interne cite un document qui ne reflète plus la réalité. L'équipe contourne le système et revient aux vieilles habitudes. Le projet meurt en silence.
La désignation d'un propriétaire semble triviale — « évidemment quelqu'un gère ça ». Mais en pratique, dans une TPE/PME, tout le monde est déjà occupé, et ajouter une responsabilité sans la formaliser signifie qu'elle tombera entre les chaises au premier pic d'activité. Les systèmes IA nécessitent une maintenance continue. Sans propriétaire, cette maintenance n'existe pas. Sans maintenance, le système se dégrade.
Pas besoin d'être technique. Curieux, disponible 2 à 4 heures par mois, et avec assez d'autorité pour décider que « cette partie ne fonctionne pas, on corrige ». Dans la plupart des TPE/PME, c'est vous, le dirigeant, au moins pour les six premiers mois.
Les cinq erreurs ont un point commun : elles se produisent avant le premier appel API. Ce sont des décisions de cadrage, pas des choix techniques. Un projet IA réussi en TPE/PME réunit systématiquement ces cinq conditions.
Aucune de ces conditions n'est technique. Toutes sont décisionnelles. C'est là que se gagne ou se perd un projet IA — pas dans le choix entre GPT-4o et Claude.