UrbanGlide Mobility : la mécanique d'un catalogue data-driven, à découvert.

Mon objectif est que mes clients gagnent 60 à 90% de temps sur les tâches répétitives, et qu'ils éliminent les erreurs de saisie.

**Note de transparence.** UrbanGlide Mobility est un projet illustratif. Le client est ici fictif, les références sont inventées, mais la mécanique est strictement identique à celle déployée chez mes clients, agences et éditeurs. Comme leurs catalogues sont confidentiels, et qu'il est important de la respecter, j'ai construit celui-ci de A à Z pour pouvoir tout vous montrer — y compris ce qui se passe dans Google Sheets mais également dans InDesign et la relation entre ces deux applications (jointure : mes propres scripts jsx Indesign).

Imaginez la situation. Une marque de mobilité urbaine prépare son catalogue 2026 : 280 dans le PIM et 70 références retenues, réparties sur trois familles (vélos électriques, trottinettes, accessoires), à publier en français, anglais, allemand et espagnol. Les données produits vivent dans un PIM (Product Information Management). Les visuels vivent dans un DAM (Digital Assets Management) séparé. Les fiches sont rédigées par trois personnes différentes, dans des feuilles de calculs envoyés par mail.

Le chef de projet éditorial a six semaines. À J-15, voici ce qu'il sait :

• Le catalogue de l'an dernier comportait des erreurs sur 3 fiches qui sont remontées par le service client après publication.
• Sur les 70 références de cette année, personne ne sait précisément lesquelles sont prêtes et lesquelles ont des trous.
• L'allemand n'a pas encore été relu. Personne ne se souvient s'il l'a été l'an dernier.

Cette situation, je la rencontre assez régulièrement chez mes clients. Elle est rarement formulée comme un problème — elle est vécue comme une tension diffuse : on sait que ça va passer, on sait aussi qu'il faudra travailler tard les derniers soirs pour rattraper les angles morts.

Sur UrbanGlide Mobility, l'audit a produit un livrable PDF de 7 pages : un tableau exhaustif des 70 références, et trois indicateurs synthétiques en pied de page.

Le verdict est tombé en une seconde de lecture :

• Produits prêts à publier : 0 / 70
• Lacunes éditoriales : 70 / 70
• Couverture langues moyenne : 4 / 4

"Le quatrième, langues, est intact. Toutes les fiches sont traduites partout. Mais chaque fiche, sans exception, présente le même trou : la spécification n°5 manquante. Sur 70 produits, sur 4 langues, sur des dizaines de visuels — c'est un seul champ qui bloque la totalité du catalogue."

L'effort de remédiation a été chiffré dans le pied de page : 2 heures de travail.

C'est précisément cet écart — entre la perception (« on a plein de choses à corriger ») et la réalité (« il manque une seule colonne, partout ») — qui justifie l'investissement de quelques jours en amont. Sans audit data-driven, l'équipe aurait passé deux semaines à chercher les trous au cas par cas. Avec l'audit, elle sait quoi faire en 2h.

C'est aussi ce qu'il y a de plus juste à raconter à un commanditaire : "regarder là où peu de gens regardent", c'est rarement spectaculaire. C'est juste systématique.

Une fois l'audit livré et la mission de fond engagée, l'architecture se met en place. Trois maillons, un sens de circulation unique :

Google Sheets ───────► Scripts VDP ───────► InDesign

(donnée vivante)    (synchronisation)    (gabarit vivant)

Pas d'aller-retour. La donnée naît et vit dans Google Sheets. Elle est consommée par InDesign à la demande, via une suite de scripts Indesign que j'ai construit (Report Maker, Table Maker, Smart Iterator, Auto-Tagger, Smart Linker). Chaque script a une mission précise dans la chaîne — synchroniser un texte, peupler un tableau, dupliquer un gabarit produit, baliser des blocs.

Le principe de fond : chacun reste maître de son terrain. Le client maîtrise Google Sheets sur le bout des doigts (calculs, listes déroulantes, validations) ; je pilote InDesign (typographie, gabarit, feuilles de styles) et mes propres scripts (non figés dans le temps et évolutifs au gré des besoins métier).

Cette architecture résout d'un coup les deux frictions classiques d'une production éditoriale data-driven :

1. Plus de copier-coller manuel entre Excel et InDesign — donc plus d'erreurs de saisie au moment de la mise en page.
2. Plus de mise en page écrasée par un import CSV maladroit — la donnée s'injecte là où elle doit, sans toucher à la composition.

Sur UrbanGlide Mobility, le dictionnaire de variables a fini par compter plus de 2 400 sorties (textes, valeurs, codes alertes, libellés UI traduits). C'est ce dictionnaire qui irrigue le gabarit InDesign à chaque rafraîchissement.

C'est la partie que peu de gens voient.

Quand on parle de Google Sheets en édition, on imagine généralement un tableur statique — une grille de cellules avec des produits dedans. Sur UrbanGlide Mobility , Google Sheets fait beaucoup plus : il calcule, agrège, audite, et surtout raisonne.

Concrètement, l'onglet Produits n'est pas qu'un référentiel. Il porte six colonnes calculées en temps réel :

• Audit_Langues — détecte si les 4 langues sont remplies
• Audit_Descriptions — vérifie la présence des descriptions courte et longue
• Audit_Specs — compte combien des 5 spécifications sont renseignées
• Audit_Photos — croise avec l'onglet medias pour vérifier qu'au moins 2 visuels sont disponibles
• Audit_Tags — confirme la présence du tag de catégorie
• Audit_Statut — synthétise les cinq précédentes en un verdict (« Prêt » / « Lacunes »)

Ces six colonnes sont des formules, pas des saisies. Le rédacteur n'a rien à cocher : dès qu'il complète un champ, le statut bascule automatiquement. Et sur la feuille vue_audit, une formule maître empile horizontalement les 70 lignes via la syntaxe française { ... \ ... \ ... }, alimentant directement le PDF de synthèse.

Plus subtil encore, la cellule d'action recommandée en pied de page est générée par la fonction =AI() de Sheets. Le prompt vit dans une cellule annexe, traduit dynamiquement par GOOGLETRANSLATE selon la langue active. Le résultat s'écrit dans la cellule consommée par le dictionnaire. À chaque régénération, l'action recommandée colle exactement à l'état réel des données.

Ce niveau d'autonomie change radicalement la nature de l'outil. Quand un seuil change (« on accepte désormais qu'une fiche soit publiable avec 4 spec sur 5 »), il ne faut pas un développeur pour rouvrir un script et redéployer. Il faut modifier une formule. Trente secondes. Le pipeline aval réagit instantanément.

C'est cette réactivité opérationnelle qui distingue une chaîne data-driven d'une simple automatisation. La différence n'est pas dans les outils. Elle est dans le fait que la règle métier vit dans le tableur, pas dans le code.

L'autre dimension, c'est l'humain.

Un catalogue de 70 produits × 4 langues ne se remplit pas seul. Il mobilise typiquement :

• Un ou deux rédacteurs pour les fiches
• Un directeur artistique pour valider la cohérence éditoriale
• Le client final pour valider les prix, la disponibilité, les dénominations
• Un expert calcul (parfois le maquettiste lui-même, parfois moi) pour les formules d'audit et de synthèse
• Un ou deux traducteurs pour les langues étrangères

Tenter cette orchestration à coups de fichiers Excel envoyés par mail produit invariablement le même résultat : trois versions divergentes au bout d'une semaine, des relances perpétuelles, et un fichier final reconstitué à la main par la personne qui a la patience.

Google Sheets traite ça nativement. Plusieurs intervenants peuvent saisir, vérifier, valider en parallèle. Les permissions sont fines (lecture seule, commentaires, édition par onglet). L'historique conserve chaque modification. Et — détail qui n'en est pas un — personne ne télécharge le fichier. Il n'y a qu'une source de vérité, vivante.

Sur UrbanGlide Mobility, la répartition pourrait ressembler à ça :

• Le rédacteur travaille sur l'onglet Produits, colonnes descriptions et specs.
• Le client a un accès direct sur les colonnes prix et disponibilité, où il peut intervenir à tout moment sans perturber la rédaction.
• Le DA consulte la feuille vue_audit pour lire l'état du catalogue à tout instant.
• Moi, je travaille sur les onglets de calcul et le dictionnaire — sans bloquer personne.

Ce que cela change dans la vie d'un projet : la production cesse d'être un flux séquentiel (rédiger puis valider puis maquetter) et devient un flux parallèle (rédiger pendant que la maquette se construit pendant que le client valide). Le délai total se réduit mécaniquement, parce que les attentes inter-équipes s'effondrent.

Côté InDesign, l'objectif n'est pas d'automatiser toute la mise en page. C'est de la rendre réactive aux données.

Le gabarit UrbanGlide Mobility se présente comme une maquette classique : pages double, blocs produits, titres, photos, tableaux de spécifications. Visuellement, rien d'extraordinaire. Mais sous le capot, chaque bloc est étiqueté. Chaque tableau est connecté à une plage Google Sheets via Table Maker. Chaque texte variable consomme une entrée du dictionnaire.

Et surtout, chaque cellule du tableau d'audit est pilotée par une feuille de styles conditionnelle, déclenchée par les colonnes _alerte_xxx de la feuille vue_audit.

Voici ce que ça donne en pratique. Prenez la fiche EB-1013 (Cargo Family+). Au moment de l'audit, ses photos sont complètes : 2/2. Le tableau affiche 2/2 en noir.

Maintenant, supposez que le client retire une photo de son DAM. Vous rouvrez Google Sheets, vous voyez l'onglet medias se mettre à jour, vous voyez la formule Audit_Photos recalculer en 1/2. Vous basculez dans InDesign et vous lancez le refresh.

• Pas de manipulation manuelle. Pas de feuille de styles à appliquer à la main. La donnée a changé, le verdict a basculé, et la feuille de styles conditionnelle a fait le reste.
• Cet effet est le cœur de la démonstration. InDesign cesse d'être un livrable figé pour devenir un consommateur de données. Le document n'est plus une photographie d'un état à un instant T — c'est une fenêtre ouverte sur l'état actuel.
• Cela change la psychologie du projet. Les équipes éditoriales arrêtent d'avoir peur du moment du « refresh final ». Elles l'attendent, parce que c'est le moment où le travail s'aligne.

Si UrbanGlide Mobility avait été une vraie mission, voici comment elle se serait déroulée. Cette structure est exactement celle que je propose à mes clients, agences et éditeurs.

• Étape 1 — Audit & Diagnostic (3 à 5 jours). J'analyse le catalogue existant ou en cours. Je produis le PDF d'audit que vous avez vu en section 2 — un tableau exhaustif avec indicateurs synthétiques. Je remets un rapport chiffré avec recommandations concrètes. Sans engagement de poursuite. Sur UrbanGlide Mobility, ce livrable seul aurait suffi à répondre à la question initiale du chef de projet : « où en sommes-nous vraiment ? »
• Étape 2 — Industrialisation (6 à 12 semaines). Si l'audit montre un vrai sujet, on construit la suite. Préparation des données dans Google Sheets (modèle, formules, validations). Scripts InDesign sur-mesure ou paramétrés depuis ma suite VDP. Automatisation des règles métier. Formation des équipes. À la livraison, vos collaborateurs sont autonomes. Sur UrbanGlide Mobility, c'est l'étape où le pipeline complet — dictionnaire, scripts, gabarit — est déployé et testé.
• Étape 3 — Maintenance & Évolution (annuel). Les workflows évoluent, les catalogues aussi. Je reste disponible pour faire évoluer les outils et accompagner vos équipes dans la durée. C'est l'étape où l'on ajuste les seuils, ajoute une langue, ouvre un nouveau type de document — sans tout reconstruire.Ce qui distingue cette méthode d'une prestation « scripts à la demande », c'est que chaque étape a son livrable autonome. Vous pouvez décider de ne pas poursuivre après l'audit. Vous repartez avec un diagnostic chiffré utilisable. Vous pouvez décider de ne pas renouveler la maintenance — vos outils continuent de fonctionner, ils sont à vous.

Vous reconnaissez votre catalogue, vos fiches produits, vos documentations dans ce qui précède ? Vos équipes passent-elles trop de temps à saisir, copier, mettre en forme manuellement des données qui existent déjà ailleurs ?

Premier échange gratuit de 30 minutes en visio pour comprendre votre projet. Si c'est pertinent, je vous propose un audit. Si l'audit montre qu'il y a un vrai sujet, on poursuit. Sinon, vous repartez avec un diagnostic clair sans engagement.