Implémenter Claude dans une PME : la méthode qu'on applique

La plupart des PME qui testent Claude suivent le même chemin. La démo impressionne. Trois semaines plus tard, l'outil est abandonné. Le problème n'est presque jamais le modèle. C'est le contexte : Claude ne sait rien de votre entreprise, de vos process, de vos décisions passées.

Chez Reversed, on construit AIOS, un système de contexte pour les PME suisses. Implémenter Claude, pour nous, ce n'est pas brancher un chatbot. C'est lui donner de quoi travailler. Voici la méthode qu'on applique, étape par étape, et les pièges qu'on voit le plus souvent.

Le vrai blocage n'est pas le modèle

Un modèle récent répond déjà très bien. Ce qui lui manque en entreprise, ce n'est pas de l'intelligence, c'est votre réalité : où vivent vos informations, comment vous décidez, ce qui a déjà été tranché. Sans ça, il devine. Avec ça, il exécute.

Notre travail consiste donc moins à rendre le modèle plus fort qu'à rendre son réveil plus riche. C'est là que se joue la différence entre une démo et un outil qui tient.

L'IA au bon endroit, pas partout

Mettre de l'intelligence artificielle partout, c'est le meilleur moyen de fragiliser un système. La plupart des tâches d'une PME n'en ont pas besoin. Parfois un simple script, un formulaire ou une règle claire font mieux, et coûtent moins cher à maintenir. Notre premier travail n'est pas d'ajouter de l'IA, c'est de cartographier vos workflows et de repérer les quelques endroits où elle change vraiment quelque chose.

Une fois ces endroits identifiés, reste à y mettre l'IA de la bonne manière. Le même outil peut servir à générer un brouillon qu'un humain valide, ou à décider seul. Le premier usage étaye votre équipe. Le second lui fait courir un risque. On choisit toujours le premier.

Et le point qu'on oublie souvent : on se sert de l'IA elle-même pour faire ce tri. Elle est excellente pour lire vos process, synthétiser où le temps se perd, et distinguer ce qui gagne à être automatisé de ce qui doit rester manuel. L'IA sert d'abord à construire le système, pas seulement à l'habiter.

1. Immersion : où vit l'information

On commence par relever où vit le contexte aujourd'hui : dans les têtes, les emails, un Drive, des fichiers éparpillés. On cherche trois gisements précis : les meetings et leurs transcripts, les offres, les décisions.

Le livrable est volontairement modeste : un CONTEXTE.md d'une vingtaine de lignes qui répond à une seule question. Que devrait savoir un excellent employé à son premier jour ? Tant que cette réponse n'existe pas, aucun outil ne tiendra.

2. Un seul cas d'usage

L'erreur classique, c'est de vouloir tout couvrir. On choisit un cas et un seul, à l'intersection de trois critères : du temps réellement perdu, des données déjà disponibles, un risque faible en cas d'erreur.

Un bon premier cas est ennuyeux et fréquent. Router des comptes rendus, préparer une offre à partir d'un modèle, retrouver une décision. Pas la démo spectaculaire. Le geste qui revient chaque semaine.

3. Les fondations : brancher Claude sur la donnée

On pose un dépôt de contexte séparé de l'opérationnel, en lecture seule au départ, avec les secrets en dehors. La règle qu'on ne lâche jamais : des pointeurs, jamais des copies. La donnée qui vit (chiffres, clients) se consulte à la source. La donnée figée (décisions, process, ton) se versionne.

C'est le rôle du protocole MCP : donner à Claude un accès direct à vos systèmes existants plutôt que du copier coller dans un chat. Sans lui, on bricole. Avec, l'agent travaille sur de la donnée fraîche.

4. La preuve

Avant d'étendre quoi que ce soit, on mesure. On prend le cas choisi, on compare l'avant et l'après devant le client, et on tranche honnêtement. Si le gain n'est pas là, on le dit et on ajuste. Un go/no-go clair vaut mieux qu'un déploiement tiède.

5. Les rituels

Un système de contexte se cultive, sinon il pourrit. On installe le minimum qui tient dans le temps : un journal de décisions (une ligne datée par décision), un routage hebdomadaire des meetings et transcripts, une validation humaine à chaque étape.

On forme aussi quelqu'un en interne, un référent qui entretient le contexte. Pas un prestataire externe indéfiniment. Le but n'est pas de vous rendre dépendants. On construit avec vous, pas à votre place.

Les pièges qu'on voit le plus

1. 01Vouloir tout automatiser d'un coup. On commence par un cas, on étend quand il est prouvé.
2. 02Copier la donnée au lieu de la pointer. Le jour où elle change, votre système ment.
3. 03Sauter l'immersion. Brancher l'outil avant de savoir où vit l'information, c'est garantir l'abandon.
4. 04Confondre démo et production. Ce qui brille en réunion n'est pas ce qui sert chaque semaine.
5. 05Retirer l'humain de la boucle. Une IA qui décide seule, en PME, c'est un risque, pas un gain.

Par où commencer cette semaine

Le premier geste ne coûte rien. Parlez à Claude cinq minutes, à voix haute ou par écrit : comment vous travaillez, ce qui vous prend du temps, quelques exemples concrets. Tirez-en un CONTEXTE.md de vingt lignes. Repérez vos trois gisements. Vous avez déjà les fondations d'un système.

Si vous voulez voir comment on structure tout ça pour une PME, on le détaille sur notre page implémenter Claude en entreprise, et plus largement sur le pilier AIOS.