Notre projet IA a échoué : ce qu’on en a appris

Un projet IA a échoué dans une petite structure. Voici pourquoi — tâche floue, pas de relecteur, outil changé chaque semaine — et ce qu’ils referaient.

Situation de départ

La structure est volontairement anonymisée. Petite équipe, activité de services, envie sincère de « ne pas rater l’IA ». Un dirigeant a vu des démos, lu des articles, entendu parler d’aides. L’intention n’était pas mauvaise. Le cadrage, lui, était absent.

Au départ, la phrase de lancement ressemblait à ceci : « on va mettre de l’IA dans nos process ». Personne ne pouvait dire quelle tâche précise serait meilleure dans quatre semaines. Chacun imaginait un truc différent : réponses clients, reporting, idées commerciales, compte-rendus. Le projet est né d’une peur de retard, pas d’un irritant mesurable.

Ils avaient du budget temps — des heures de réunion — et peu de méthode. On ne publie ici ni montant dépensé, ni nom d’outil « coupable ». L’échec ne vient pas d’une marque. Il vient de trois habitudes qu’on retrouve dans beaucoup de PME pressées.

On changeait d’outil dès que ça coinçait. On aurait dû changer de question.

Ce qui a été essayé

Phase un : ateliers internes « découverte ». Chacun testait ce qu’il voulait. Résultat : des anecdotes amusantes, zéro usage commun. Phase deux : choix d’un premier outil, puis d’un deuxième parce que « l’autre a l’air mieux », puis d’un troisième après une démo vendeuse. Chaque migration coûtait une semaine d’apprentissage perdu.

Phase trois : tentative de « tout automatiser » sur les réponses sortantes. Sans règle de relecture. Des messages sont partis trop vite, avec des formulations que l’équipe n’assumait pas. Pas de catastrophe publique majeure — ils ont freiné à temps — mais assez pour que la confiance interne chute. Les collègues ont commencé à dire « encore l’IA » avec un sourire crispé.

Ils ont aussi essayé de coller des extraits de dossiers pour « aller plus vite ». Là, le frein est venu d’une personne plus prudente : stop. Trop de données, trop flou sur ce qui pouvait sortir. Cette personne avait raison ; le projet n’avait pas de liste « on colle / on ne colle pas ».

Comparé à des parcours plus cadrés, comme celui raconté dans PME et IA Booster, il manquait l’autodiagnostic qui réduit le périmètre. Ici, le périmètre grossissait à chaque réunion. Plus on en parlait, moins on savait quoi livrer le vendredi.

Ils ont même inventé un tableau de suivi avec des colonnes trop ambitieuses : idées, outils, « quick wins », formation, communication. Le tableau était beau. Il ne produisait rien. Chaque ligne ajoutait une intention sans propriétaire. Au bout d’un mois, le document faisait office de preuve d’activité alors qu’aucun usage n’était tenu. C’est le moment où le dirigeant a compris que le projet avait déjà échoué — avant même de l’avouer à voix haute.

Une tentative de « champion IA » interne a aussi planté. On a désigné quelqu’un sans lui donner de temps ni de mandat de relecture. La personne s’est retrouvée à répondre à toutes les questions, sans pouvoir dire non. Elle a craqué. Le rôle est devenu un symbole, pas une responsabilité. Ils ont depuis interdit les titres creux : soit une tâche avec temps dédié, soit rien.

Ce qui a coincé

Première raison : pas de tâche claire. « Améliorer la productivité » n’est pas une tâche. Une tâche, c’est « rédiger une réponse type pour tel motif, à partir de cinq faits, relu par Marie ». Sans cette précision, chaque essai partait dans une direction différente. Les réunions tournaient au débat d’opinion sur l’avenir du travail.

Deuxième raison : personne pour relire. L’outil proposait ; personne n’était nommé pour valider avant envoi. Tant que c’était du brouillon interne, ça passait. Dès que ça touchait un client ou un partenaire, le vide de responsabilité est devenu dangereux. « On verra bien » n’est pas un processus.

Troisième raison : outil changé chaque semaine. À chaque friction, la tentation était de croire que le logiciel suivant résoudrait le problème. En réalité, ils reportaient l’apprentissage et la discipline. Au bout de deux mois, personne ne maîtrisait rien ; tout le monde était fatigué.

Ces trois raisons se nourrissaient l’une l’autre. Sans tâche claire, on changeait d’outil pour « trouver mieux ». Sans relecteur, on découvrait les erreurs trop tard, donc on imputait le problème au logiciel. Le cercle infernal a duré jusqu’à ce qu’une personne dise en réunion : « on n’a toujours pas de phrase pour décrire ce qu’on fait ». Silence. Puis abandon du grand projet.

Ce qui reste

Ils ont arrêté le « grand projet ». Ils ont écrit une page : une tâche autorisée, un relecteur, un outil pour un mois, une règle de données. Puis ils ont recommencé tout petit — un seul type de message interne — avec chronométrage honnête. Si la relecture dépassait le gain, on arrêtait sans drame.

Ce qui reste surtout, c’est le récit partagé. Dire « on s’est plantés » en interne a débloqué la parole. Les collègues osent maintenant demander « quelle tâche ? » dès qu’on parle d’IA. C’est devenu un filtre culturel plus utile que n’importe quelle démo.

Ils ne cherchent plus à transformer cet échec en succès rétrospectif. Ils le gardent comme garde-fou. Quand un commercial propose un outil miracle, ils sortent les trois questions : tâche, relecteur, durée d’essai. Si la réponse est vague, ils passent leur tour.

Ce qu’ils referaient dès la première semaine, en résumé narratif : une demi-journée pour écrire la tâche et la règle de données ; un mois sur un seul outil ; un rendez-vous de quinze minutes chaque vendredi pour noter si la relecture coûte trop ; une décision claire à J+30 — on garde, on ajuste, ou on arrête. Pas de deuxième outil « pour comparer » pendant ce mois. Pas de réunion supplémentaire « stratégie IA » sans livrable.

Ils acceptent aussi que certains sujets restent hors IA pour l’instant. Tout n’a pas besoin d’être assisté. Dire non à un usage flou a redevenu une compétence de direction, pas un signe de retard. Ce retournement — du fantasme à la sélection — est le vrai reste de l’échec.

Pour aller plus loin