L'IA, par les usages. Pas par les promesses.
La carte n'est pas le territoire. Beaucoup de projets IA produisent une représentation précise d'un problème partiellement compris. Nous commençons par le territoire — ce que vos équipes font vraiment, ce qu'elles savent sans l'avoir formalisé — avant de décider quoi construire.
Pourquoi tant de projets IA ne s'installent pas.
La technologie fonctionne. Les démonstrations impressionnent. Et pourtant, sur le terrain, rien ne s'installe vraiment — et ce n'est presque jamais un problème technique. Deux mondes s'ignorent.
Le monde des spécialistes IA
Ils construisent la solution avant d'avoir compris le problème : le réflexe de modélisation court-circuite la phase d'analyse. Et avec les outils actuels, on produit une application en quelques semaines — le risque de « construire vite et faux » n'a jamais été aussi élevé.
Le monde de l'entreprise
Ce qu'elle fait bien, où elle déraille, ce qu'il faut vérifier — personne ne leur a vraiment expliqué. Et le savoir métier est souvent tacite : des règles intériorisées que personne n'a jamais eu besoin de formaliser. L'IA ne peut pas l'extraire automatiquement — il faut une démarche d'explicitation.
Ce pont entre les deux mondes, c'est ce que nous construisons. Pas en apportant l'IA comme une réponse — en commençant par les questions que personne n'a posées : dans quel ordre vos experts travaillent-ils vraiment ? quelles règles appliquent-ils sans les avoir jamais formalisées ? qu'est-ce qui les alerte, et pourquoi ? Ce que les gens décrivent qu'ils font et ce qu'ils font réellement divergent presque toujours — c'est l'écart entre la carte et le territoire, et c'est lui qu'on va chercher en premier.
Un outil fonctionnel, construit sur des fondations non validées.
Ce n'est pas l'incompétent qui construit l'outil le plus risqué — c'est souvent l'expert très compétent, précisément parce que sa maîtrise technique lui permet d'aller très vite, avant d'avoir posé les bonnes questions. Voici ce que les questions de base ont révélé sur un outil réel, développé en interne, qui fonctionnait.
Le périmètre n'avait pas été défini
L'outil générait et contrôlait des livrables métier. Combien ? De quelle nature ? Selon quelles variantes ? Les réponses étaient floues — et la sophistication ne change rien à la fragilité de fondations instables.
Le workflow réel n'avait jamais été formalisé
Dans quel ordre les experts traitent-ils les éléments, avec quelle logique ? Personne n'avait posé la question avant de concevoir la navigation de l'outil.
Du savoir tacite avait été encodé comme s'il était validé
Des pratiques implicites — jamais écrites, jamais validées — étaient intégrées dans la logique de l'outil. L'effet normal d'une démarche qui part de documents plutôt que des experts.
La compétence technique ne protège pas des angles morts — elle les déplace. Le problème est perçu, assimilé, traduit en architecture — sans avoir été confronté aux usages réels.
Le succès partiel est plus dangereux que l'échec franc. Comme ça marche à peu près, on continue à construire — et l'outil devient sophistiqué, et légèrement désadapté. Un échec franc force à reconsidérer.
L'extériorité n'est pas un handicap, c'est une méthode. Parce qu'on ne connaît pas le métier, on pose les questions que l'expert ne se pose plus — et on refuse que ce qui « va de soi » reste implicite.
Former un référent IA
La personne qui portera le sujet chez vous : diagnostic, usages, gouvernance. Parcours modulable selon le point de départ.
→ 02Former vos équipes
Dirigeants, encadrement, fonctions support : décider, prioriser, cadrer — et ancrer l'usage dans les équipes.
→ 03Vous accompagner du diagnostic à l'autonomie
Quand il faut aussi construire l'outil : diagnostic sur le terrain, développement avec vos experts, formation et transfert.
→L'ignorance méthodique
Ne pas connaître votre métier est une ressource : poser les questions que l'expert ne se pose plus, rendre visible le tacite — à condition d'en faire une méthode, pas une excuse.
La représentation provisoire
Nous arrivons avec des hypothèses formulées — grille, schéma, modèle — soumises à confrontation. L'expert est en position de validateur, pas d'inventeur.
Le pourquoi avant le comment
Avant toute analyse : pourquoi cette activité existe-t-elle, quel résultat réel produit-elle, pour qui ? La réponse déplace souvent le périmètre du problème.
La compétence reste chez vous
Ce que nous construisons ensemble doit survivre à notre départ : les outils, les réflexes, la capacité à adapter quand les situations changent.
L'impact se mesure à trois et six mois — en termes métier, pas en satisfaction.
Un premier échange. Sans engagement.
Vous repartez avec une idée claire de ce qui vaut la peine d'être fait — et de ce qui ne l'est pas.
Parlons de votre projet