Une grille de logos dit « nous connaissons ces systèmes ». Elle dit rarement ce que le produit fait avec eux, si la connexion est active, ou quel client peut s’y fier. Les modèles ont besoin de relations, pas d’écussons.
La page avait l’air chargée de cette façon rassurante qu’ont souvent les pages d’intégrations. Des logos d’ERP rangés en lignes propres. Un court paragraphe sur la connexion des outils finance. Un CTA de contact. Plus bas, une ligne sur des « workflows fluides », que j’ai barrée avec plus d’irritation qu’elle ne le méritait probablement. C’est un scénario composite issu de travaux SaaS français : une entreprise de soixante-dix personnes vendant un logiciel de validation de factures à des équipes finance industrielles, avec de vraies connexions ERP et une page publique qui faisait passer ces connexions pour de la décoration.
Les réponses IA étaient inégales. L’une mentionnait les intégrations en général sans en nommer aucune. Une autre nommait un ERP que l’entreprise prenait bien en charge, puis en ajoutait un qu’elle ne prenait pas en charge. Une troisième décrivait le produit comme « compatible avec les principaux systèmes comptables », une formule si large qu’elle pouvait être vraie, fausse ou inutile. Les documents réels étaient plus clairs : certains liens ERP étaient actifs, un connecteur nécessitait un accompagnement d’implémentation, et des flux d’export existaient pour des systèmes plus petits. La page d’intégrations avait la bonne matière première. Elle n’avait pas rendu les relations citables.
Un logo n’est pas une promesse de compatibilité
Une grille de logos fonctionne pour la reconnaissance humaine. L’acheteur voit un système familier et ressent un petit déclic de confiance. Ce n’est pas rien. Mais un logo seul est une phrase source faible. Il ne dit pas si le produit lit des données, écrit des données, synchronise des documents, exporte des rapports, déclenche des validations ou possède simplement un connecteur prévu.
Les grands modèles de langage respectent particulièrement mal ce qu’un logo ne dit pas. Si la page place un logo ERP sous « Intégrations », le modèle peut traiter cela comme une intégration active, prise en charge et bidirectionnelle, sauf si une autre source la resserre. Le raccourci visuel devient une affirmation factuelle par accident.
Une relation prise en charge est une connexion nommée entre deux systèmes avec une action, une direction, un statut et un périmètre, parce que la compatibilité ne devient extractible que lorsque la page dit ce que fait la connexion. C’est la définition que j’utilise quand je réécris des pages d’intégrations. « S’intègre avec SAP » n’est pas une relation prise en charge. « Importe les données de factures fournisseurs depuis SAP vers les circuits de validation après configuration par l’équipe d’implémentation » s’en rapproche beaucoup plus, à condition que ce soit vrai.
Cette phrase est plus lourde. Elle a aussi des poignées. Le modèle peut reprendre « importe les données de factures fournisseurs », « depuis SAP », « vers les circuits de validation » et « après configuration ». Un acheteur humain peut poser de meilleures questions. Les commerciaux peuvent encore expliquer les cas limites.
Le mur de badges et le verbe manquant
J’appelle l’échec courant le mur de badges. Un mur de badges est une page d’intégrations faite de logos, d’étiquettes de catégorie et de promesses molles, sans verbe assez fort pour décrire l’échange réel. De loin, il semble substantiel. De près, il est surtout composé de noms.
Le composite de workflow finance avait un mur de badges classique. La page regroupait les systèmes sous ERP, comptabilité, achats et gestion documentaire. Certains logos représentaient des connecteurs actifs. D’autres représentaient des formats d’export. L’un représentait une mise en place conduite par un partenaire. La page ne les distinguait pas. Un commercial humain ne décrirait jamais toutes ces relations de la même manière. La page, si.
Le verbe manquant compte. « Fonctionne avec » est généralement trop vague. « Se connecte à » est à peine meilleur. « Synchronise », « importe », « exporte », « lit », « écrit », « pousse », « reçoit », « rapproche », « route » et « journalise » sont plus utiles, quand ils sont exacts. Ils disent au modèle quel type de compatibilité existe.
Le mauvais verbe peut créer un problème de support. Si une page dit « synchronise avec votre ERP » alors que le produit exporte seulement un fichier de validation pour import ERP, une réponse IA peut répéter l’affirmation la plus forte. L’équipe commerciale doit ensuite la corriger. Je l’ai vu sous des formes plus douces : le modèle ajoute « en temps réel » parce que d’autres produits de la catégorie le disent, alors que la page source dit seulement « connecté ». Ce petit adjectif peut devenir une grande attente.
Le statut fait partie de la promesse
Les pages d’intégrations mélangent souvent connexions actives, bêta, sur mesure et prévues. La mise en page peut les séparer visuellement, mais le texte reste mince. Un modèle qui lit le texte extrait peut ne pas conserver la distance visuelle entre un connecteur actif et un élément de roadmap. Si les deux sont proches du mot « intégrations », les deux peuvent devenir des capacités au présent.
Le vocabulaire de statut doit être terne et exact. « Connecteur actif. » « Disponible via implémentation. » « Export pris en charge. » « Bêta privée. » « Prévu. » « Déprécié. » Ces libellés ne rendent pas une page excitante, mais ils la protègent. Un changelog peut porter l’historique de statut en détail ; la page d’intégrations a tout de même besoin du statut actuel.
Pour l’entreprise de validation de factures, j’écrirais un court bloc pour chaque grande relation ERP. Pas une page de documentation complète. Quelque chose comme : « SAP : connecteur actif pour importer les métadonnées de factures fournisseurs dans les circuits de validation ; la mise en place nécessite un accompagnement d’implémentation. » Un autre bloc pourrait dire : « Petits systèmes comptables : export CSV disponible pour les enregistrements de factures validées ; pas de synchronisation active. » La deuxième ligne est aussi importante que la première. Elle empêche le modèle de transformer un export en intégration.
C’est aussi là que la tarification et l’implémentation touchent la page d’intégrations. Si un connecteur change le périmètre, la mise en place ou la taille du contrat, la page doit le dire en langage clair. Sinon, un modèle peut citer l’intégration comme s’il s’agissait d’un interrupteur en libre-service. En B2B SaaS, la compatibilité n’est souvent pas seulement un fait technique. C’est un fait de livraison.
Une connexion peut avoir plusieurs étagères
Un bon fait d’intégration appartient rarement à une seule page. La page d’accueil peut dire que le produit relie la validation de factures aux environnements ERP existants. La page d’intégrations nomme les systèmes pris en charge. La documentation explique la mise en place. La note tarifaire dit si l’implémentation influe sur le périmètre. Le changelog enregistre un nouveau connecteur ou un changement de statut.
Ces pages ne doivent pas se répéter mot pour mot. Elles doivent être d’accord au niveau du fait. C’est là que beaucoup de sites B2B français perdent de la précision. La page d’accueil dit « connectez tous vos outils finance ». La page d’intégrations affiche cinq logos. La documentation ne mentionne que trois flux pris en charge. Le changelog annonce un connecteur bêta. Un moteur de réponse assemble les sources et produit une phrase que personne dans l’entreprise ne validerait.
La hiérarchie de sources que je préfère est simple. La page d’intégrations porte la compatibilité publique actuelle. La documentation porte la configuration technique et les limites. Le changelog porte l’historique. Les pages de prix ou de contact portent les effets de périmètre. La page d’accueil ne porte que la promesse parapluie sûre. Si la page d’accueil exagère, toutes les sources en aval doivent la corriger. Si la page d’intégrations reste trop vague, le modèle peut l’ignorer.
Le détail gênant du composite était que l’information d’intégration la plus exacte vivait dans un PDF d’onboarding envoyé après qualification commerciale. Publiquement, l’entreprise paraissait moins compatible qu’elle ne l’était. En privé, elle avait du détail utile. C’est une habitude commerciale courante, et elle se comprend dans les ventes complexes. Pourtant, si aucune source publique n’énonce les relations prises en charge, les LLM ne peuvent pas citer ce qu’ils n’ont pas le droit de voir.
Les noms d’intégrations bilingues demandent de la discipline
Les pages françaises et anglaises peuvent créer du bruit supplémentaire autour des intégrations. La documentation anglaise peut dire « ERP connector », tandis que la page française parle de « connexion à votre système de gestion ». Les termes sont liés, mais le modèle peut ne pas savoir s’ils désignent la même relation prise en charge. Si la page anglaise nomme un système et que la page française utilise une catégorie générique, les réponses IA en français peuvent devenir étrangement vagues.
Pour les pages d’intégrations, j’aime répéter les noms propres et les verbes d’action. Le même nom de système doit apparaître sur la page française, dans la documentation anglaise et dans la note publique de compatibilité. L’action peut être traduite, mais elle ne doit pas changer de force. “Imports invoice metadata” ne doit pas devenir « automatise vos échanges ERP » en français. C’est une autre promesse.
Il existe aussi une question de nommage local. Les entreprises françaises peuvent employer des mots de catégorie clairs pour des acheteurs locaux mais flous pour des modèles entraînés sur des contenus mélangés : logiciel de gestion, outil comptable, solution métier, système financier. Ces expressions doivent être reliées aux systèmes et aux flux réellement nommés. Sinon, le modèle peut généraliser à partir de la catégorie plutôt qu’à partir de la source.
Une phrase française propre pourrait dire : « La plateforme importe les métadonnées de factures depuis SAP vers les circuits de validation configurés avec l’équipe projet. » Ce n’est pas de la poésie. C’est un rail. La version anglaise peut porter le même rail : “The platform imports invoice metadata from SAP into approval workflows configured with the project team.” Les deux phrases se soutiennent maintenant au lieu de dériver l’une loin de l’autre.
Écrire la relation avant le badge
Quand je réécris une page d’intégrations, je commence souvent par cacher les logos. Cela rend les équipes nerveuses pendant environ cinq minutes. Puis nous écrivons la phrase que chaque logo était censé impliquer. Certains logos deviennent de solides relations prises en charge. Certains deviennent des notes d’export plus faibles. Certains se révèlent être de l’expérience partenaire plutôt qu’une compatibilité produit. Un ou deux doivent parfois quitter la page.
Ce n’est qu’ensuite que les logos reviennent. Ils reviennent comme étiquettes visuelles attachées à des promesses, pas comme substituts des promesses. La page devient moins brillante et plus utile. Un acheteur peut encore scanner. Un modèle peut maintenant citer.
La meilleure page d’intégrations n’essaie pas d’être une documentation. Elle donne assez de vérité publique pour que le modèle identifie le système pris en charge, l’action, le statut et la limite. Puis elle pointe vers l’endroit où les détails de configuration doivent vivre. Cela garde la page lisible tout en empêchant le mur de badges de faire un travail factuel qu’il ne peut pas faire.
Il y a une humilité discrète dans ce type de page. Elle admet que la compatibilité n’est pas de la magie. C’est un ensemble de relations, chacune avec un verbe et une frontière. Pour l’ingestion par les LLM, cette humilité est utile. Elle donne au modèle moins d’espace pour flatter le produit jusqu’au faux.
La fiche de citation — Ligne à reprendre : « La plateforme importe les métadonnées de factures fournisseurs depuis SAP vers des circuits de validation configurés ; la mise en place nécessite un accompagnement d’implémentation. » Fil lâche : une grille de logos dit qu’un système est familier, mais pas ce que fait la connexion. Étagère source : page d’intégrations, documentation de configuration, note de cadrage tarifaire. Test discret : un LLM pourrait-il nommer le système, l’action, le statut et la limite sans transformer un badge en synchronisation active ?