Nous avons récemment audité un client potentiel. Ils gagnaient 10 millions de dollars de revenus. Ils avaient 47 applications Shopify installées. Ils avaient trois applications contextuelles différentes (une seule était active). Ils disposaient de deux plateformes d’évaluation parce que « la migration était difficile ». Ils avaient un programme de fidélité qui ne communiquait pas avec leur plateforme de messagerie. Il s’agit de la pile Frankenstein. Il est cousu avec de l’espoir et du ruban adhésif. C’est lent. C’est cher. Et c’est fragile. Cet article explique comment auditer votre pile et concevoir un écosystème de Commerce unifié.

Pourquoi Maison Code en parle

Chez Maison Code Paris, nous opérons à l’intersection du Luxe et de la Technologie. Nous avons vu trop de marques investir des millions dans la “Transformation Digitale” pour ne voir qu’une croissance plate.

Nous en discutons car le ROI de cette stratégie est souvent mal compris. Il ne s’agit pas seulement de “modernisation”, mais de maximiser la Valeur Vie (LTV) de chaque interaction numérique.

Pourquoi Maison Code discute d’architecture avec les PDG

Nous ne sommes pas que des « codeurs ». Nous sommes des “Architectes Systèmes”. Nous voyons des PDG signer des contrats pour de nouveaux outils SaaS flashy sans se demander : « Est-ce que cela se connecte à nos données existantes ? Le résultat est des Silos de données.

L’équipe marketing estime que le LTV est de 50 € (sur la base de GA4).
L’équipe financière estime que le LTV est de 80 € (sur la base de l’ERP).
L’équipe d’assistance estime que le LTV est de 20 € (selon le Helpdesk). Personne n’est d’accord. Nous discutons de stratégie d’intégration car Mauvaise architecture = Mauvaises données = Mauvaises décisions. Nous transformons le Frankenstein en Machine.

1. Le processus d’audit (la méthode Marie Kondo)

La première étape est un audit impitoyable.

Identifiez : répertoriez tous les outils pour lesquels vous payez. (Vérifiez le relevé de carte de crédit).
Vérifier l’utilisation : Connectez-vous au panneau d’administration. À quand remonte la dernière fois que quelqu’un s’est connecté ? Si > 3 mois, Tuez-le.
Vérifier la connexion : cet outil renvoie-t-il des données à la source unique de vérité (Shopify/ERP) ?
Consolider :
- Klaviyo peut-il envoyer des SMS ? Oui. Alors pourquoi payez-vous pour Attentive ?
- Shopify peut-il proposer des offres groupées ? Oui. Pourquoi payer pour ReCharge/Bold ?
- Gorgias peut-il gérer les DM Instagram ? Oui. Pourquoi utiliser un outil social distinct ? Objectif : Réduire la taille de la pile de 30 %. Chaque application que vous supprimez améliore la vitesse du site et réduit les risques de sécurité.

2. La « Source Unique de Vérité » (SSOT)

Dans une pile Frankenstein, chaque application pense qu’elle est le maître.

Mailchimp pense qu’il est propriétaire de l’enregistrement utilisateur.
Salesforce pense qu’il est propriétaire de l’enregistrement utilisateur.
Shopify pense qu’il est propriétaire de l’enregistrement utilisateur. Lorsqu’un utilisateur met à jour son e-mail, qui gagne ? Règle d’architecture n°1 : Définissez le SSOT. Pour la plupart des marques D2C, Shopify (ou l’ERP) est le SSOT pour les commandes et les clients. Toutes les autres applications sont des « esclaves ». Ils lisent sur Shopify. Ils écrivent à Shopify. Ils n’accumulent pas de données.

3. L’économie des API (Rest vs GraphQL)

(Voir Couche API). L’intégration s’appuie sur des API (Application Programming Interfaces).

REST : L’ancienne norme. “Donnez-moi l’utilisateur 123”. Le serveur envoie l’utilisateur 123.
GraphQL : la norme moderne. “Donnez-moi l’e-mail de l’utilisateur 123 et le total de la dernière commande”. GraphQL permet la « minimisation des données ». Vous récupérez uniquement ce dont vous avez besoin. C’est plus rapide et moins cher. Lorsque vous choisissez un nouvel outil SaaS, demandez au CTO : « Disposent-ils d’une API GraphQL ? Si la réponse est non, réfléchissez-y à deux fois. Ils vivent en 2015.

4. Middleware : La Colle

Parfois, l’application A ne peut pas communiquer directement avec l’application B. Vous avez besoin d’un Middleware.

La voie amateur : Zapier. (Bon pour le prototypage, mauvais pour l’échelle. Cher et opaque).
The Pro Way : iPaaS (Integration Platform as a Service).
- Des outils comme Celigo, Mulesoft ou Workato.
- Ils gèrent les « tentatives » (Et si l’API est en panne ?).
- Ils gèrent les « limites de taux » (ne faites pas planter l’ERP).
- Ils fournissent des journaux. Le middleware est l’agent de la circulation. Il garantit un flux de données fluide et sans plantage.

5. Construire ou acheter (la question éternelle)

(Voir Build vs Buy). Devriez-vous acheter une « application de gestion des retours » (Loop Returns) ou créer un portail personnalisé ? La Matrice :

Est-ce au cœur de votre IP ?
- Votre « Processus de retour » est-il unique ? Est-ce que cela définit votre marque ?
- Oui -> Construisez-le.
- Non (c’est standard) -> Achetez-le.
L’écosystème d’applications est-il mature ?
- Existe-t-il d’excellentes applications ? -> Acheter.
- Les applications sont-elles terribles ? -> Construire. Pour 90 % des fonctionnalités (Avis, Chat, Fidélité), Acheter est la réponse. Ne réinventez pas la roue. Réinventez le moteur.

6. Architecture sans tête (la séparation ultime)

(Voir Pourquoi Headless). Dans un Monolith (thème Shopify standard), le « Frontend » et le « Backend » sont collés ensemble. Si vous installez une application, elle injecte du code directement dans votre frontend. Cela ralentit le site. Dans Headless, le Frontend est séparé (React). Les applications se connectent via l’API. Ils ne peuvent pas « injecter » du code lent. Ils sont chimiquement séparés. C’est l’hygiène ultime pour une pile technologique. Cela empêche “Plugin Bloat” de tuer votre taux de conversion.

7. Entreposage de données (Le Lac)

Où vont toutes les données ? Vous avez besoin d’un entrepôt de données (Snowflake, BigQuery). Extrayez les données de Shopify, Facebook, Google Ads, Klaviyo. Chargez-le dans BigQuery. Transformez-le. Visualisez-le dans Looker Studio / Tableau. Cela permet de poser des questions complexes : “Quels sont mes clients les plus rentables qui ont acheté des Chaussures en juillet et qui venaient d’Instagram ?” Shopify Analytics ne peut pas répondre à cette question. SQL peut. (Voir Attribution SQL).

8. En temps réel ou par lots

Les anciens systèmes utilisaient le « traitement par lots ». “Chaque nuit à minuit, nous synchronisons l’inventaire.” En 2025, c’est inacceptable. Si j’achète le dernier article à 23h59 et que vous l’achetez à 00h01… nous avons une survente. Vous devez passer à Architecture basée sur les événements (Webhooks).

Événement : « Commande créée ».
Action : « Mettre à jour l’inventaire (immédiatement) ». Les données en temps réel évitent les cauchemars du service client.

9. Risques de sécurité liés à la fragmentation

Chaque application que vous installez est une porte dérobée. Si vous donnez un accès en « lecture/écriture » à une application aléatoire « Free Shipping Bar » construite par un adolescent dans un sous-sol… Et cette application est piratée… Le pirate informatique a accès à vos données clients. Gestion des risques liés aux fournisseurs :

Limiter les autorisations. (Une barre d’expédition a-t-elle besoin d’accéder aux adresses des clients ? Non).
Examinez les étendues OAuth.
Utilisez “App Proxy” pour masquer les clés sensibles. (Voir Risque du fournisseur).

10. Commerce composable vs Monolith

L’industrie fait le buzz autour du « Composable ». Cela signifie choisir le « meilleur de la race » pour chaque fonction.

CMS : Contenu.
Recherche : Algolia.
Panier : Shopify.
Revue : Yotpo. C’est puissant, mais dangereux. Le Monolith (Tout-en-Un) : Plus facile à gérer. 90% des marques devraient rester ici. Composable : Flexibilité infinie, complexité infinie. Uniquement pour les marques faisant >\€50M GMV. N’achetez pas de Ferrari si vous n’avez pas d’équipe de mécaniciens.

11. Le coût de la maintenance (dette technique)

Chaque application que vous ajoutez a une « taxe ». Il ne s’agit pas seulement des frais d’abonnement mensuels. Il s’agit des Frais de maintenance.

Qui met à jour les clés API lorsqu’elles expirent ?
Qui corrige l’intégration lorsque Shopify met à jour son API ?
Qui surveille les journaux ? Si vous disposez de 47 applications, vous avez besoin d’un ingénieur à temps plein juste pour garder les lumières allumées. Stratégie : calculez le TCO (coût total de possession). Frais du logiciel + heures de maintenance = coût réel. Simplifiez la pile pour réduire la taxe.

11. La documentation comme culture

Dans une pile de Frankenstein, la connaissance vit dans la tête d’une seule personne. “Demandez à Bob comment les points de fidélité se synchronisent.” Si Bob part, l’entreprise est paralysée. Le correctif : Notion/Confluence. Documentez chaque intégration. “Le champ A dans Shopify correspond au champ B dans Salesforce.” la documentation n’est pas une réflexion après coup. C’est un atout. (Voir Marque 100 ans).

12. Conclusion

Une Clean Stack est un avantage concurrentiel. Cela vous permet d’avancer rapidement. Cela vous permet de faire confiance à vos données. Il permet à votre site de se charger instantanément. Ne soyez pas un collectionneur. Soyez conservateur. Votre pile doit être élégante, minimale et puissante. Comme votre marque.

Service de nettoyage numérique ?

Nous effectuons des audits de pile technologique, des consolidations d’applications et des implémentations de middleware.

Réparer ma logique. Engagez nos Architectes.