Chapitre 10 / 10

Pourquoi ça échoue

Un projet d'assistant interne échoue rarement à cause du modèle. Ce chapitre nomme les trois raisons qu'on observe le plus souvent sur le terrain.

Un échec, ici, désigne un assistant construit mais jamais utilisé par les équipes au quotidien, ou abandonné après quelques semaines faute de résultat fiable.

Un périmètre trop large dès le départ

Vouloir couvrir tous les documents et tous les usages dès le premier jour retarde le premier résultat utile et dilue l'effort. Un périmètre restreint (chapitre 9) livre plus vite et se corrige plus facilement.

Des données sales

Un assistant reflète la qualité des documents qu'on lui donne. Des dossiers mal rangés ou des doublons non résolus produisent des réponses incohérentes, quel que soit le modèle choisi.

Personne ne s'en sert

Un outil techniquement fiable mais jamais intégré dans le réflexe quotidien des équipes retombe vite dans l'oubli. L'adoption se travaille autant que la technique.

Questions fréquentes

Ces trois raisons sont-elles évitables ?

Oui, toutes les trois se préviennent par un périmètre restreint au départ, un audit des données avant construction, et l'implication des équipes dès le début.

Le modèle est-il rarement en cause ?

Rarement en première cause. La plupart des échecs observés tiennent au périmètre, aux données ou à l'adoption, pas au modèle lui-même.

Que faire si un projet a déjà échoue chez vous ?

Reprendre un périmètre plus restreint sur les documents les plus utilisés au quotidien, plutôt que de relancer le même projet à l'identique.

Tous les chapitres

Faire le point sur ma situation

Un périmètre trop large dès le départ

Des données sales

Personne ne s'en sert

Questions fréquentes

Tous les chapitres

Prêt à passer à l'action?

Avant de partir...