Un fichier brand.json sur votre site web fournit des informations de marque juridiquement contraignantes sous forme de données structurées et lisibles par machine. Ce fichier peut contenir des informations telles que le nom, les services, l'adresse, les langues, les moyens de contact, les horaires d'ouverture et les profils officiels, le tout à partir d'une source unique. Un fichier brand.json améliore l'unicité technique de votre marque, mais ne garantit pas sa présence dans les systèmes d'IA comme ChatGPT, Gemini, Perplexity et autres.
Pour une PME, l'avantage ne réside pas dans le format de fichier supplémentaire, mais dans une réponse définitive à la question : quelles informations concernant l'entreprise sont correctes et où ces informations sont-elles conservées ?
Un fichier brand.json ne remplace pas un site web convivial. Ce fichier constitue une version supplémentaire, lisible par machine, des informations relatives aux marques déposées, déjà accessibles au public.
brand.json pour votre site web : Tâches et limitations
Un fichier brand.json regroupe les données clés de l'entreprise et de la marque au format JSON , un format textuel d'échange de données. Ce fichier est lisible par les humains ; plus important encore, il peut être traité par les sites web, les applications, les interfaces, les systèmes de recherche et les services basés sur l'intelligence artificielle.
Le terme « brand.json » ne désigne pas actuellement une norme web obligatoire publiée par un organisme de normalisation reconnu. Un gestionnaire de marque open source, par exemple, utilise le même nom. Cependant, la structure et l'interprétation d'un fichier « brand.json » dépendent de l'intégration technique spécifique. Par conséquent, différents systèmes peuvent utiliser des noms de champs et des structures différents.
Par conséquent, n'adoptez pas un modèle sans l'avoir vérifié au préalable. Définissez un schéma clair, documentez les champs et assurez-vous de la cohérence des données. Un fichier syntaxiquement valide contenant des horaires d'ouverture incorrects sera néanmoins factuellement erroné.
Quelles informations sur la marque doivent figurer dans le dossier ?
Dans le cadre de mon travail auprès des entreprises familiales, je constate fréquemment le même problème : le nom de l’entreprise est orthographié différemment sur le site web et dans la fiche Google My Business, les services ne sont pas désignés de manière cohérente en allemand et en italien, et un ancien numéro de téléphone est toujours enregistré sur un profil de réseau social. Un fichier brand.json devrait permettre de centraliser ces informations lorsque de telles incohérences sont particulièrement problématiques.
Identité et positionnement
- Nom de marque public : Le nom sous lequel l'entreprise communique et est recherchée.
- Nom légal : Nom complet de l'entreprise pour une identification sans ambiguïté.
- Brève description: une description objective de l'entreprise, de son groupe cible et de ses offres.
- services: Noms de services approuvés, accompagnés de brèves explications et d'identifiants stables.
- Langues: Langues dans lesquelles les conseils, les ventes ou l'assistance sont effectivement proposés.
Emplacement, accessibilité et entretien
- Emplacements: Adresses complètes et, le cas échéant, zones géographiques de responsabilité.
- Moyens de contact : Adresse électronique générale, numéro de téléphone et site web officiel.
- Horaires d'ouvertures: Des horaires réguliers avec des jours de la semaine et un fuseau horaire clairement définis.
- Profils officiels : Profils d'entreprise confirmés sur les plateformes pertinentes.
- Version et date de modification : Informations sur le versionnage et la dernière revue technique.
Les données personnelles ne doivent figurer dans le dossier public que si leur publication est nécessaire, approuvée en interne et conforme à la loi. Pour de nombreuses PME, une adresse générique comme info@entreprise.it est suffisante . Par mesure de précaution, il est déconseillé de publier les numéros de téléphone portable privés, les extensions internes ou les adresses électroniques personnelles.
Données de marque au format JSON : Exemple d’une PME du Tyrol du Sud
L'exemple suivant décrit une entreprise artisanale fictive du Tyrol du Sud. Sa structure est volontairement concise. Il s'agit d'un modèle possible, mais pas d'un schéma brand.json universellement contraignant.
{
"schemaVersion": "1.0",
"version": "2026.03",
"lastUpdated": "2026-03-20",
"publicName": "Alpenwerk",
"legalName": "Alpenwerk Holzmanufaktur GmbH",
"descriptions": {
"de": "Planung und Fertigung maßgefertigter Möbel für private und gewerbliche Räume in Südtirol.",
"it": "Progettazione e produzione di mobili su misura per spazi privati e commerciali in Alto Adige."
},
"website": "https://www.alpenwerk.example",
"languages": [
{
"code": "de",
"name": "Deutsch"
},
{
"code": "it",
"name": "Italiano"
}
],
"services": [
{
"id": "moebel-nach-mass",
"names": {
"de": "Möbel nach Maß",
"it": "Mobili su misura"
}
},
{
"id": "innenausbau",
"names": {
"de": "Innenausbau",
"it": "Arredamento d'interni"
}
}
],
"locations": [
{
"id": "hauptsitz-bozen",
"names": {
"de": "Hauptsitz Bozen",
"it": "Sede di Bolzano"
},
"address": {
"street": "Musterweg 12",
"postalCode": "39100",
"city": "Bozen",
"region": "Südtirol",
"countryCode": "IT"
},
"timeZone": "Europe/Rome"
}
],
"contacts": {
"email": "info@alpenwerk.example",
"phone": "+39 0471 000000"
},
"openingHours": [
{
"days": ["monday", "tuesday", "wednesday", "thursday"],
"opens": "08:00",
"closes": "17:00"
},
{
"days": ["friday"],
"opens": "08:00",
"closes": "12:00"
}
],
"officialProfiles": [
{
"platform": "linkedin",
"url": "https://www.linkedin.com/company/alpenwerk-example"
},
{
"platform": "instagram",
"url": "https://www.instagram.com/alpenwerk.example"
}
]
}Que signifient les différents champs ?
`schemaVersion` fait référence à la version du modèle de données utilisé. Si un champ est renommé ultérieurement ou si la structure est étendue, une application technique peut identifier le schéma selon lequel le fichier est structuré.
`version` fait référence à l'état actuel de l'enregistrement de données. Pour les petites entreprises, la combinaison de l'année et du mois est souvent suffisante. `lastUpdated` indique la date de la dernière modification du contenu au format année-mois-jour.
Le nom public et le nom légal permettent de distinguer le nom de marque communiqué du nom légal de l'entreprise. Cette distinction évite qu'un nom de marque court ne soit utilisé par erreur comme nom complet de l'entreprise.
La section « Descriptions » contient de brèves descriptions approuvées, classées par langue. Le multilinguisme ne se limite pas à une simple traduction linguistiquement correcte : les énoncés doivent être cohérents quant à leur contenu dans toutes les langues.
Chaque service utilise un identifiant unique. La valeur « moebel-nach-mass » reste inchangée, tandis que les noms affichés varient selon la langue. Cela permet aux systèmes techniques d'identifier correctement les noms allemand et italien d'un même service.
Le champ « lieux » sépare le nom du lieu de l’adresse structurée. Le fuseau horaire est particulièrement important pour les heures d’ouverture, les détails des rendez-vous ou les lieux multiples.
La section « Contacts » ne contient volontairement que les coordonnées générales. La section « Heures d'ouverture » indique les heures d'ouverture habituelles. Les horaires d'ouverture spéciaux, les jours fériés et les jours de fermeture de l'entreprise doivent être précisés dans un champ supplémentaire, le cas échéant.
Les profils officiels ne doivent contenir que des profils vérifiés gérés par l'entreprise elle-même. Les annuaires professionnels et les mentions éditoriales ne sont pas considérés comme des profils officiels.
De l'information dispersée à la source unique de vérité
Le fichier brand.json ne doit pas être géré manuellement comme un fichier distinct de celui du site web. Pour votre PME, il est conseillé d'utiliser une source unique de données fiables : une source de données unique et faisant autorité qui alimente le site web, les données structurées et les autres canaux de communication.
Le processus opérationnel comprend sept étapes :
- 1. Recueillir des informations sur la marque : Vérifiez les sites web, les profils d'entreprise, les annuaires, les offres et les documents internes pour déceler d'éventuelles incohérences.
- 2. Publier les faits : La direction ou les responsables de marque décident quels noms, descriptions, services et méthodes de contact sont contractuels.
- 3. Déterminer la source centrale : Une base de données ou un système de contenu bien tenu devient la source faisant autorité.
- 4. Générer du JSON : Les données libérées sont transférées automatiquement ou manuellement dans la structure convenue, dans des conditions contrôlées.
- 5. Effectuer la validation des données : La syntaxe, les champs obligatoires, les types de données, les URL et l'exactitude technique sont vérifiés.
- 6. Prononcer publiquement : Le fichier reçoit une adresse HTTPS stable et un type de contenu approprié.
- 7. Synchroniser les modifications : Les nouveaux services, les changements d'horaires d'ouverture ou un déménagement sont d'abord mis à jour dans la source centrale, puis transférés aux éditions liées.
Les avantages économiques des données de marque lisibles par machine proviennent de la maintenance centralisée et des dépenses contrôlées sur plusieurs canaux.
Une étude de cas avant-après issue de la pratique des PME
Voici un exemple typique tiré de mon travail : le site web en allemand indique « Beratung und Planung » (Conseil et planification), le site italien seulement « Consulenza » (Conseil), la fiche Google My Business mentionne « Planungsbüro » (Bureau d’urbanisme), et Instagram utilise un ancien nom de produit. De plus, le site web indique une fermeture à 18 h, tandis qu’un annuaire d’entreprises mentionne 17 h.
Précédemment : informations contradictoires sur plusieurs canaux
- Les noms des produits sont reformulés à chaque publication.
- Les traductions ne peuvent pas être attribuées sans ambiguïté au même service.
- Les horaires d'ouverture sont modifiés manuellement à plusieurs endroits.
- Les anciens profils et documents restent en ligne sans être remarqués.
- Les employés ignorent quelle description fait foi.
Par la suite : publication des faits provenant d'une source centrale
- Chaque service reçoit un identifiant stable et des noms approuvés pour chaque langue.
- Le site web et le fichier brand.json puisent leurs informations dans la même base de données de contenu.
- Les horaires d'ouverture sont modifiés à un moment donné, puis mis en œuvre de manière contrôlée.
- Les profils officiels sont documentés et régulièrement mis à jour.
- Les responsabilités et les dates de modification sont traçables.
Il en résulte moins d'incohérences, un effort de maintenance réduit et des informations plus fiables sur la marque . Après plus de 20 ans d'expérience dans le branding, le développement web et la digitalisation, je considère cette clarté organisationnelle plus importante que le format des fichiers individuels.
Séparez les fichiers brand.json, Schema.org, llms.txt et le contenu du site web.
Plusieurs éditions peuvent utiliser les mêmes informations sur la marque, mais servir des objectifs différents. Aucun des niveaux suivants ne remplace les autres.
Le contenu visible du site web informe et guide.
Le contenu visible d'un site web est conçu pour les utilisateurs. Il explique les liens entre les services, répond aux questions, précise le positionnement et indique le moyen de contact approprié. Par conséquent, un fichier brand.json ne doit pas entraîner une description trop succincte ou incompréhensible des services ou des lieux présentés sur le site.
Le fichier brand.json regroupe les informations approuvées sur les marques.
Le fichier brand.json fournit un ensemble de données compact sur la marque. Son format est adapté à un traitement ultérieur contrôlé, aux applications internes et aux intégrations techniques. Les systèmes qui récupèrent ou interprètent ce fichier dépendent de son implémentation.
Schema.org décrit les entités dans le contexte d'un site web.
Les données structurées selon Schema.org sont généralement intégrées directement aux sites web, souvent au format JSON-LD. Schema.org est une initiative communautaire qui définit des types et des propriétés pour les organisations, les adresses, les lieux, les points de contact, les offres et les services.
Schema.org possède un vocabulaire défini. Un fichier brand.json, en revanche, peut utiliser son propre schéma de données documenté. Ces deux formats peuvent être générés à partir d'une même source centrale, mais ils ne sont pas automatiquement interchangeables.
llms.txt rassemble des notes et des liens vers du contenu.
Le 3 septembre 2024, Jeremy Howard a publié le fichier llms.txt , proposant un fichier Markdown contenant des informations générales concises, des notes et des liens vers des contenus complémentaires. Ce fichier sert principalement de guide pour les modèles de langage et ne constitue pas une base de données exhaustive sur les marques.
Vous trouverez une explication plus détaillée des limitations et des applications possibles dans notre article sur llms.txt pour les PME.
Maintenance et gouvernance : Qui tient à jour les informations relatives à la marque ?
Un fichier brand.json requiert une personne responsable. Dans les petites entreprises, un gestionnaire de données dédié n'est pas nécessaire. Souvent, la direction, un membre de l'équipe marketing ou l'administrateur du site web se charge de la validation technique.
Une répartition claire des rôles comprend quatre tâches :
- Responsabilité professionnelle : Qui décide quelles informations sur les marques sont correctes et approuvées ?
- Responsabilité technique : Qui vérifie la génération, la validation des données et leur publication ?
- Responsabilité linguistique : Qui veille à ce que les termes multilingues véhiculent la même signification ?
- Responsabilité du contrôle : Qui compare régulièrement la source centrale avec le site web et les profils officiels ?
Les éléments déclencheurs habituels des mises à jour comprennent un déménagement, de nouvelles coordonnées, un changement d'horaires d'ouverture, un changement d'image de marque, des services nouveaux ou supprimés, l'ouverture d'un nouvel emplacement et de nouvelles versions linguistiques. Ces modifications doivent d'abord être effectuées dans la source unique de référence, puis déployées sur les canaux connectés.
Gestion des versions sans complexité inutile
Pour la plupart des PME, un système de versionnage simple suffit. Utilisez un champ pour la version de la structure, un autre pour l'état des données et une date de modification unique. Pour les modifications importantes, un bref journal des modifications internes est également conseillé.
Un nouveau logo dont les champs restent inchangés peut ne nécessiter qu'une nouvelle version des données. En revanche, une structure modifiée avec de nouveaux champs obligatoires requiert une nouvelle version du schéma. Cette distinction permet aux applications connectées de traiter correctement les modifications structurelles.
Publication technique du fichier brand.json
Avant publication, il ne suffit pas de vérifier que le fichier s'affiche correctement dans le navigateur. Un fichier brand.json utilisable nécessite une livraison technique fiable et une relecture professionnelle.
Livraison technique
- Adresse HTTPS stable : par exemple https://www.deine-domain.it/brand.json.
- Type de contenu approprié : de préférence application / json.
- Syntaxe JSON valide : Aucune virgule manquante, aucun guillemet non fermé, ni aucun commentaire.
- URL accessibles : Vérifiez le site web, les pages de localisation et les profils officiels pour détecter d'éventuelles erreurs.
Révision du contenu
- Champs obligatoires définis : Définir en interne les détails qui ne doivent jamais manquer.
- Données actuelles : La date de modification et le contenu doivent correspondre.
- Accord relatif au contenu : Comparez les noms, les services et les coordonnées avec les informations visibles.
- Aucune donnée personnelle inutile : Ne publiez que ce qui est nécessaire au public.
- Schéma documenté : Consignez les noms des champs, les types de données et la logique du langage pour les extensions ultérieures.
Une vérification de syntaxe détermine si le JSON est techniquement lisible. Une vérification fonctionnelle s'assure que le contenu est correct et à jour. Ces deux vérifications font partie de la validation des données. Pour plus d'informations sur les vérifications JSON-LD associées, notre guide sur la validation de schéma explique pourquoi les vérifications techniques et de contenu doivent être effectuées séparément.
Comment btlabs Core fournit de manière centralisée des données de marque
Chez Berger+Team, nous considérons l'image de marque, le site web et les livrables techniques comme un système intégré. Des informations telles que notre adresse à Bolzano, nos coordonnées et la description de nos services (image de marque, conception web, marketing digital, intégration d'IA et conseil) ne doivent pas figurer séparément dans chaque document. Ces informations nécessitent une base de contenu commune.
btlabs Core est un référentiel de contenu centralisé permettant de générer le contenu du site web et des fichiers exploitables par machine, comme un fichier brand.json. La gestion du contenu multilingue est structurée afin de garantir la cohérence et la pertinence des différentes versions linguistiques, réduisant ainsi la duplication de la maintenance et les incohérences.
L'ajout de canaux tels que des boutiques, des applications, des fonctions de réservation ou des agents IA constitue une étape d'expansion possible et ne fait pas partie intégrante de chaque implémentation. Le facteur déterminant réside dans les besoins spécifiques de l'entreprise. Sur la page dédiée aux sites web compatibles avec l'IA grâce à btlabs Core, nous expliquons plus en détail les fondements techniques et les coûts potentiels.
Même pour les données de marque IA gérées de manière centralisée, le principe suivant s'applique : aucun système ne peut contraindre un modèle de langage à mentionner une marque ou à citer une source spécifique. Une base de données solide améliore les conditions d'un traitement correct, mais ne remplace ni un contenu crédible, ni la notoriété de la marque, ni les signaux de confiance externes, ni un positionnement clair.
Questions et réponses concernant brand.json
Où doit-on stocker le fichier brand.json ?
Une adresse stable à la racine de votre domaine est facile à communiquer, par exemple /brand.json . Il est essentiel que cela nécessite une URL HTTPS persistante, une accessibilité publique et une transmission correcte au format JSON.
Existe-t-il des champs obligatoires pour un fichier brand.json ?
Non, il n'existe actuellement aucune norme web brand.json universellement contraignante avec des champs obligatoires. Pour votre entreprise, définissez au moins les champs suivants comme obligatoires en interne : nom public, raison sociale, description, services, coordonnées, adresse, langues, version et date de modification.
Comment représenter fidèlement le multilinguisme ?
Utilisez des codes de langue non ambigus tels que « de » et « it » et attribuez aux traductions le même identifiant stable de performance ou de localisation. Vérifiez non seulement la langue, mais aussi l’équivalence technique des énoncés.
Un fichier brand.json peut-il contenir des données personnelles ?
Techniquement, c'est possible, mais il convient d'être prudent d'un point de vue professionnel et juridique. Il est préférable de publier des informations de contact professionnelles générales et de préciser au préalable si le traitement des données personnelles est nécessaire, autorisé et conforme à la législation sur la protection des données.
À quelle fréquence le fichier doit-il être mis à jour ?
Mettez à jour le fichier brand.json dès que son contenu subit une modification pertinente. De plus, je recommande de le comparer à votre site web, aux profils de votre entreprise et à vos données internes de référence au moins une fois par trimestre.
Comment puis-je valider un fichier brand.json ?
Commencez par vérifier la syntaxe JSON à l'aide d'un validateur approprié ou d'un test automatisé. Ensuite, effectuez un contrôle fonctionnel des noms, URL, numéros de téléphone, versions linguistiques, horaires d'ouverture et champs obligatoires par rapport à la source de données centrale.
Le fichier brand.json remplace-t-il le balisage Schema.org ?
Non. Le balisage Schema.org décrit le contenu et les entités d'un site web à l'aide d'un vocabulaire maintenu par la communauté, tandis qu'un fichier brand.json fournit un profil de marque distinct. Les deux doivent utiliser les mêmes données sources partagées.
Un fichier brand.json est-il identique à un fichier llms.txt ?
Non. Le fichier brand.json organise les informations de la marque au format JSON, tandis que llms.txt est un fichier Markdown suggéré pour l'orientation et les liens vers les contenus importants. Ces deux fichiers peuvent se compléter, mais ils ont des objectifs différents.
Les systèmes d'IA prennent-ils automatiquement en compte un fichier brand.json ?
Non, la prise en compte automatique par tous les systèmes d'IA n'est ni prouvée ni systématique. Son utilisation réelle dépend des robots d'exploration, des moteurs de recherche, des applications et des intégrations spécifiques. Par conséquent, un contenu web visible et des données structurées restent essentiels.
Quelle est la première étape la plus importante pour une PME ?
Ne commencez pas par programmer le fichier, mais par diffuser les informations essentielles de votre marque. Si le nom, les services, les adresses et les moyens de contact ne sont pas cohérents, un fichier brand.json permet simplement de rendre ces incohérences lisibles par machine.
Conclusion : Commencez par clarifier les informations relatives à la marque, puis générez un fichier JSON.
Un fichier brand.json est utile lorsqu'il provient d'une source unique et fiable. Ce fichier permet de centraliser les informations de marque de manière compacte, vérifiable et techniquement réutilisable. Pour les PME, cela se traduit par une maintenance simplifiée, un contenu multilingue plus cohérent et une base plus fiable pour les sites web, les services numériques et les applications d'IA.
La démarche logique consiste à : établir les faits, clarifier les responsabilités, déterminer une source centrale, valider le JSON, le rendre public et assurer un suivi régulier. Sans données sources liées, même un fichier brand.json techniquement correct ne peut garantir la cohérence.
