Entre le dernier échange d’avant-vente et le lancement d’un projet, une partie décisive de l’information disparaît souvent. Elle reste dans des notes individuelles, dans le souvenir d’une démo ou dans un document que personne ne sait vraiment retrouver. Le problème n’est pas le manque de conversations. C’est l’absence d’un contexte métier structuré, maintenu et transmissible.
Modjo Knowledge ouvre une piste intéressante pour les équipes qui veulent donner à leurs outils d’IA un socle commun. À condition de ne pas lui demander ce qu’il ne promet pas : ce n’est ni une séparation native par client, ni un système de droits par projet, ni un remplacement de la gouvernance documentaire. C’est une base globale d’organisation qui peut aider à conserver les repères nécessaires entre vente, lancement et delivery.
Pourquoi le passage avant-vente vers delivery reste fragile
Une vente B2B ne transmet pas seulement un périmètre ou une date de démarrage. Elle contient des éléments qui déterminent la qualité du delivery : les termes employés par le client, les rôles réellement influents, les décisions déjà prises, les contraintes de sécurité, les usages qui ne doivent pas être cassés, les objections levées, les zones encore floues et les engagements de cadrage.
Quand ce contexte est dissocié du projet, l’équipe de delivery recommence les mêmes questions. Le client doit réexpliquer ses priorités. Un nouveau consultant interprète une expression métier autrement. La revue de lancement devient une opération de reconstitution plutôt qu’un moment de décision.
Pour un intégrateur ou une ESN, cette perte de continuité a des effets très concrets :
le démarrage paraît plus lent que prévu ;
la confiance se fragilise dès les premières semaines ;
les arbitrages historiques sont découverts trop tard ;
les règles métier se retrouvent dans des échanges privés plutôt que dans un référentiel maintenu ;
l’IA reçoit des morceaux de contexte, mais pas une source lisible et contrôlée.
La réponse n’est pas d’empiler des documents. Il faut décider quel contexte doit survivre à un changement d’interlocuteur, qui en est responsable et comment il sera relu.
Ce que Modjo Knowledge documente aujourd’hui
La documentation officielle de Modjo présente Knowledge comme une zone dédiée, administrée depuis Settings vers Knowledge. La gestion est réservée aux administrateurs. Il est possible d’ajouter une entrée texte structurée ou d’importer un document au format .md ou .txt, dans une limite annoncée de 5 Mo par fichier.
Une entrée texte peut convenir à une description d’entreprise, une méthode commerciale, un catalogue, un guide opérationnel ou un repère de vocabulaire. Pour un document importé, Modjo indique un état de traitement puis un statut Ready. L’indexation peut prendre jusqu’à cinq minutes.
Une fois la connaissance disponible, elle est annoncée comme accessible automatiquement par Ask Anything et par les Agents Modjo. La plateforme évalue la pertinence par rapport à la requête : elle ne promet donc pas que chaque document sera injecté à chaque question.
C’est précisément ce qui rend la structuration importante. Un fichier générique, interminable ou périmé aide peu. Un contexte court, daté, nommé et relié à une décision est beaucoup plus facile à retrouver et à évaluer.
« La continuité entre avant-vente et delivery ne dépend pas d’un compte rendu plus long. Elle dépend d’un contexte métier que l’équipe peut relire, challenger et transmettre. »
David Boukhors, fondateur de Cloud Girafe
La limite à accepter avant de concevoir le dispositif
La documentation indique aussi une limite essentielle : à ce stade, la connaissance est globale à l’organisation. Il n’existe pas de sélection par Agent. Cette base ne doit donc pas être utilisée comme si elle isolait nativement un client, un projet ou une équipe.
Pour une ESN, cette limite doit guider la gouvernance dès le départ :
- ne placer dans la base que des informations compatibles avec sa portée globale ;
- éviter les secrets client, les éléments contractuels sensibles ou les informations personnelles non nécessaires ;
- distinguer les règles communes de l’entreprise des éléments qui doivent rester dans un espace projet doté de ses propres droits ;
- décrire explicitement le niveau de confidentialité et le propriétaire de chaque entrée ;
- organiser les documents par client, projet ou phase pour faciliter la lecture, sans confondre cette organisation avec un cloisonnement d’accès.
Cette prudence n’enlève rien à l’intérêt du dispositif. Elle évite surtout un faux sentiment de sécurité. Une bonne mémoire d’entreprise est d’abord une mémoire gouvernée.
Un modèle de contexte utile pour un intégrateur Salesforce
Au lieu de déposer les comptes rendus bruts, une équipe peut créer des fiches de contexte concises. Le but est de donner un point de départ stable, pas de reproduire tout l’historique.
1. L’entreprise et son vocabulaire
Commencez par les repères que les nouveaux intervenants mettent habituellement plusieurs semaines à comprendre : activités et unités métier, noms internes des produits, équipes et processus, termes à ne pas confondre, systèmes déjà en place, contraintes réglementaires ou opérationnelles connues.
Une phrase comme « le dossier partenaire » peut recouvrir une opportunité, une demande de service ou un espace documentaire selon l’entreprise. Cette ambiguïté doit être visible avant de devenir une erreur de configuration.
2. Les rôles et décisions
La fiche peut ensuite identifier les rôles, sans transformer la base globale en annuaire sensible : qui arbitre les priorités, qui connaît le processus actuel, qui valide les données ou les accès, quelles décisions ont déjà été prises, quelles questions restent ouvertes.
Le critère n’est pas la quantité de noms. C’est la possibilité de comprendre qui doit être associé à quel arbitrage.
3. Le périmètre et les points de vigilance
Dans une mission Salesforce, les difficultés ne sont pas toujours dans la fonctionnalité demandée. Elles peuvent se trouver dans une synchronisation, une règle de partage, un doublon historique, une adoption inégale ou une dépendance à une automatisation.
Une fiche de contexte peut faire apparaître le périmètre retenu et ce qui est hors périmètre, les intégrations connues, les règles métier à ne pas altérer sans validation, les risques déjà identifiés et les hypothèses à confirmer au lancement.
4. Les méthodes par phase
Enfin, les équipes peuvent relier le contexte à des gestes concrets : questions de qualification avant cadrage, checklist de lancement, format de décision, méthode de recette, critères de passage en hypercare et procédure de transmission à l’équipe qui reprend le sujet.
Le résultat est plus utile qu’un compte rendu figé : une équipe sait ce qu’elle doit vérifier et pourquoi.
Exemple : préparer un lancement sans repartir de zéro
Imaginons une entreprise qui souhaite fiabiliser son suivi commercial dans Salesforce. L’avant-vente a mis au jour trois réalités : une définition variable des leads qualifiés, une équipe service client qui consulte le CRM sans toujours l’alimenter, et une intégration avec un outil marketing à préserver.
Le référentiel de contexte peut alors contenir une définition courte des étapes commerciales, avec les zones à arbitrer, un vocabulaire partagé entre commerce, marketing et service client, la liste des flux connus et la source de vérité de chaque donnée, les décisions déjà validées et celles qui nécessitent un atelier, ainsi que la checklist du lancement.
Lorsqu’un consultant rejoint la mission, il ne reçoit pas une promesse que l’IA connaît tout. Il reçoit une structure qui lui permet de poser de meilleures questions. Ask Anything ou un Agent peut mobiliser la connaissance lorsqu’elle est pertinente, tandis que l’équipe garde la responsabilité des décisions.
Le bon rythme de maintenance
Une mémoire d’entreprise devient vite moins fiable si personne ne la maintient. Il faut donc prévoir un rôle de propriétaire de contenu. Ce rôle peut être tenu par une personne de l’avant-vente, du delivery, des opérations ou de la gouvernance, selon l’organisation.
Son travail ne consiste pas à tout écrire. Il consiste à arbitrer ce qui doit devenir une source commune, ce qui doit rester dans l’espace projet, ce qui est devenu obsolète, ce qui doit être versionné et ce qui mérite d’être reformulé pour rester compréhensible.
Une revue mensuelle légère peut suffire pour les éléments communs. À chaque lancement de projet, une revue dédiée permet de confirmer que le vocabulaire, les décisions et les points de vigilance restent justes.
La documentation Modjo recommande de privilégier un contenu précis et contextualisé, plutôt que des fichiers très longs et peu structurés. C’est une règle de gouvernance autant qu’une règle d’indexation.
Cinq garde-fous à mettre en place
Désigner un propriétaire
Chaque source doit avoir un responsable et une date de dernière revue. Sans cela, une information ancienne peut sembler officielle.
Écrire pour la réutilisation
Une entrée doit répondre à une question opérationnelle : que faut-il savoir avant cet atelier, quelle règle protège ce flux, qui valide cette décision ? Les notes narratives sans objectif sont plus difficiles à retrouver.
Séparer contexte commun et données sensibles
La base globale ne remplace pas un espace sécurisé par client ou par projet. La portée documentée impose de choisir avec soin les informations ajoutées.
Utiliser des formats simples
Les formats .md et .txt invitent à une structure légère : titres explicites, listes courtes, date, propriétaire et liens vers les sources autorisées. La limite de 5 Mo par fichier est une bonne incitation à éviter les archives massives.
Tester les questions réelles
Après l’indexation, testez les questions qui reviennent réellement : quelle est la définition de cette étape, quels flux doivent être protégés, quelle décision a été prise au cadrage ? Si le contenu reste en statut Processing au-delà de cinq minutes, la documentation conseille de supprimer puis réimporter le fichier, puis de contacter le support si le problème persiste.
Pour aller plus loin : l’IA ne remplace pas le passage de relais
La valeur d’une base de connaissances n’est pas de faire disparaître les ateliers de lancement. Elle permet de les rendre plus utiles. L’équipe ne passe plus son temps à retrouver les faits élémentaires. Elle peut discuter des arbitrages, des risques et de la responsabilité de chaque décision.
Pour un intégrateur, c’est un moyen de rendre la promesse de continuité vérifiable. On peut documenter ce qui a été compris avant la vente, ce qui a été confirmé au lancement et ce qui doit être transmis à l’étape suivante.
Cloud Girafe accompagne les équipes qui souhaitent clarifier leurs processus, leurs données et leurs règles avant de faire évoluer Salesforce. Un audit ciblé peut identifier les zones où la connaissance métier s’est dispersée et proposer un plan de reprise réaliste : demander un second avis Salesforce.
FAQ
Modjo Knowledge est-il déjà disponible dans tous les workspaces ?
La documentation publique consultée le 17 juillet 2026 décrit encore un déploiement progressif. La fonctionnalité est toutefois déjà visible dans le workspace Cloud Girafe. Sa disponibilité doit donc être vérifiée dans chaque environnement.
Qui peut administrer la base de connaissances ?
La documentation indique un accès réservé aux administrateurs, depuis Settings vers Knowledge.
Quels fichiers sont acceptés ?
Les documents .md et .txt sont indiqués comme formats acceptés. Une entrée texte peut aussi être créée directement. La limite annoncée est de 5 Mo par fichier.
Peut-on isoler la connaissance par client ou par Agent ?
Non, pas selon la documentation actuellement consultée. La connaissance est globale à l’organisation et aucun sélecteur par Agent n’est disponible. Il ne faut donc pas y placer des informations qui exigent un cloisonnement natif par client ou projet.
L’IA utilisera-t-elle toujours la base de connaissances ?
La documentation indique que l’IA évalue la pertinence de la connaissance pour la question posée. Une source claire et ciblée est donc préférable à une archive longue et hétérogène.
