Growth : remplacer dix tableaux de bord par une file d'actions

En quelques jours, Growth est passé d'un tableau de bord en lecture seule à un centre de décision qui rapproche commerce, acquisition, SEO, performance web, email et social. L'objectif n'est plus de montrer davantage de chiffres : il est de dire quoi traiter maintenant, pourquoi, et avec quelles preuves.

Un point important sur la méthode : contrairement à la plupart des projets documentés jusque-là dans ce journal, Growth n'a pas été construit avec Claude. Le cadrage, l'architecture, le développement, les tests, le déploiement et cette documentation ont été réalisés presque entièrement dans ChatGPT avec Codex. Claude n'est intervenu qu'à la marge sur ce chantier.

Le problème

Les informations utiles existaient déjà, mais elles vivaient dans des outils différents : Odoo pour les ventes, la marge et le stock ; Shopify pour le flux e-commerce ; GA4 et Google Ads pour la mesure ; Search Console et Merchant Center pour la visibilité ; Brevo pour l'email ; Lighthouse pour la performance ; les plateformes sociales pour l'organique et le paid.

Chaque outil sait produire son tableau de bord. Aucun ne répond seul à une question simple : quelle action mérite réellement notre temps aujourd'hui ?

Ce qui a été construit

• un accueil limité aux actions prioritaires ;
• une barre principale pour poser une question, ouvrir une preuve, rafraîchir les données ou préparer une action ;
• un rapprochement Odoo ↔ Shopify et une lecture croisée GA4, Ads et ventes réelles ;
• un backlog SEO issu de Search Console, complété à la demande par DataForSEO ;
• des contrôles Merchant Center, Lighthouse, liens, erreurs HTTP, Brevo et réseaux sociaux ;
• un moteur commun réutilisable pour une future instance Haute Fidélité dans HL OS ;
• un garde-fou : toute écriture sensible reste soumise à validation humaine.

Comment le système est découpé

Le produit repose sur deux dépôts de code et une plateforme de données. Cette séparation évite que l'interface Growth reconstruise ses propres chiffres ou accède directement aux données brutes.

1. Le dépôt cobra-data fabrique la donnée fiable. Il collecte Odoo et Shopify en lecture seule, intègre les autres sources analytiques, nettoie, déduplique, rapproche les identifiants et construit les indicateurs métier.
2. BigQuery conserve les différentes couches. cobra_raw reçoit les copies techniques, cobra_staging les fiabilise, cobra_marts publie les vues métier stables et cobra_audit garde la trace des traitements.
3. Le dépôt applicatif cobra-pilotage, dans apps/growth, transforme les faits en décisions. Growth lit uniquement les marts autorisés et les indicateurs agrégés de fraîcheur. Il ne peut ni modifier BigQuery, ni consulter raw ou staging, ni écrire dans Odoo ou Shopify par défaut.

Comment circule une action

La collecte, les contrôles, la détection des anomalies et le classement peuvent tourner automatiquement. Une action sensible suit en revanche un contrat explicite : preuve, aperçu, validation humaine, exécution autorisée, journal et mesure avant/après.

Le changement de philosophie

Le produit avait commencé comme un tableau de bord. C'était utile pour vérifier que les données remontaient, mais insuffisant pour changer la façon de travailler. La page d'accueil a donc été retournée : les indicateurs détaillés sont devenus des preuves secondaires. Le premier écran présente quelques propositions classées par impact, confiance, effort et urgence.

Le flux cible est volontairement lisible : demande → analyse → aperçu du changement → validation → exécution → journal → mesure. Growth peut lire et rafraîchir automatiquement. Il ne doit pas modifier un prix, un stock, une campagne, un email ou une publication sociale sans le droit correspondant.

La difficulté réelle

Le code de l'interface n'était pas la partie la plus coûteuse. Le travail difficile consistait à décider quelle source croire et à empêcher les rapprochements trompeurs. Odoo reste la vérité commerciale. Shopify décrit le flux web. Les plateformes publicitaires donnent leur attribution déclarée. GA4 décrit le comportement observé. Ces chiffres peuvent être comparés, mais ils ne doivent jamais être confondus.

Le premier apprentissage important est venu de cette règle : lorsque la couverture analytics est insuffisante par rapport aux commandes réelles, Growth doit recommander de fiabiliser la mesure avant de proposer un déplacement de budget.

Temps comprimé et valeur de développement

Le cadrage a commencé pendant le week-end, la première trace projet date du 31 août et la première version a été mise en production le 1er septembre.

La valeur de remplacement du développement actuel se situe autour de 45 à 55 k€ HT, avec un point central proche de 50 k€ HT. Une industrialisation complète — supervision durable des connecteurs, boucle avant/après, droits fins et documentation d'exploitation — porterait plutôt l'ensemble vers 65 à 80 k€ HT.

Ce chiffrage estime un coût de reconstruction externe, pas la valorisation financière du logiciel ni un retour sur investissement. Repères : baromètre Malt 2026 et synthèse des TJM IT en France.

Ce que ça change

La valeur n'est pas d'avoir ajouté un nouveau tableau de bord à la collection. Elle est de pouvoir progressivement cesser d'ouvrir dix interfaces pour reconstituer une situation.

Growth rassemble les faits, propose le prochain travail et conserve les preuves accessibles à l'expert. Le même cœur pourra servir un commerçant comme Cobra ou un éditeur comme Haute Fidélité, avec des données, comptes et règles séparés.

La prochaine étape n'est donc pas d'ajouter cent graphiques. C'est de fermer la boucle : mesurer ce qui s'est réellement passé après chaque action, puis rendre la recommandation suivante meilleure que la précédente.