Un éditeur de vitrine, un catalogue et un bureau de confirmation dans un seul back-office, reliés au réseau de livraison d’IntiGo — pour qu’un vendeur tunisien passe de « j’ai des produits » à « le colis est parti » sans quitter IntiGo.
Les partenaires expédient déjà leurs colis avec IntiGo. Le module ecommerce leur donne la boutique devant ces colis : une boutique qu’un assistant IA peut préparer à partir de quelques photos et d’une courte description, un éditeur de vitrine à thèmes, un catalogue avec variantes et coupons, une équipe qui confirme par téléphone les commandes en paiement à la livraison, un tracking Meta qui résiste aux bloqueurs de pub, et un passage vers le réseau logistique. J’ai construit le côté vendeur de ce module ; je connais aussi le reste de la boucle (livraison, validation WhatsApp, Facebook et marketing) et je le décris plus bas comme une connaissance, pas comme mon code. Le module tourne aujourd’hui sur staging derrière une allowlist de soft launch.
“De quoi un vendeur a-t-il besoin entre « un acheteur a cliqué » et « un colis a quitté l’entrepôt » ?”
Ce dont les vendeurs se souviennent, c’est la partie la plus courte : envoyer les photos d’un premier produit, écrire ou coller sa description et son prix, et un assistant IA prépare un brouillon complet en une dizaine de minutes : nom, logo, couleurs, page d’accueil, fiche produit et textes en français et en arabe, avec des visuels produit construits à partir de la vraie photo. Le vendeur relit, ajuste avec l’assistant du constructeur et publie. Le parcours manuel (cinq étapes guidées, environ 45 minutes) reste à un clic, et changer de chemin ne fait rien perdre.
Ce n’est pas un générateur à la Lovable. Les outils « prompt vers code » remettent à l’utilisateur du code source à comprendre et à maintenir. Ici, le modèle n’écrit jamais de HTML, de CSS ni de gabarit : il rend du JSON, nettoyé champ par champ puis appliqué par les services du moteur de thèmes, de sorte que le résultat est toujours une boutique valide dans le constructeur que le vendeur connaît déjà. Cette contrainte est la fonctionnalité. Un commerçant veut une boutique qui marche en dix minutes, pas une liberté illimitée, et un format fermé se teste, se plafonne et se corrige.
Il faut rendre à chacun son dû : l’assistant lui-même est le travail d’un collègue. Ce que j’ai construit, c’est le moteur qu’il pilote (sections, réglages, préréglages sectoriels, brouillons et révisions), et j’ai intégré l’assistant au back-office vendeur puis fusionné dans staging. Il fonctionne parce que le moteur est déclaratif.
Le tableau de bord vendeur est construit autour d’une seule question. Avant tout graphique, il montre trois files de travail (commandes à confirmer, stock à racheter, paniers abandonnés à relancer sur WhatsApp), chacune avec un chiffre et un bouton, puis une prise en main guidée qui chiffre la prochaine étape en minutes. Viennent ensuite les taux, chacun avec son numérateur et son dénominateur, et un tiret honnête plutôt qu’un 0 % trompeur quand il n’y a rien à mesurer.
Deux détails que je défendrais en revue de design : le tableau de bord et la page de confirmation affichent exprès deux taux de confirmation, l’un par commande traitée (qualité des agents) et l’autre par commande reçue (retard), pour qu’un taux parfait ne cache pas une file qui grandit ; et le menu latéral est groupé par ce que le vendeur veut faire, avec des badges en direct qui reprennent les chiffres des cartes d’action, donc les nombres concordent toujours. Les captures et une lecture écrite de chaque écran sont plus haut et plus bas. Les chiffres viennent d’une boutique de test sur staging.
Construit par moi (côté vendeur) : l’éditeur de vitrine à thèmes et ses modèles, le back-office vendeur, le CRM de l’équipe de confirmation avec son score de risque, l’intégration Pixel Meta, API de conversions et catalogue, la récupération des paniers abandonnés et les coupons. Tout ce qui figure dans cette liste, je l’ai conçu et implémenté ; c’est la partie visible dans les captures.
Connu, mais pas construit par moi : la livraison (création du colis, suivi chauffeur et logistique, validation WhatsApp au premier scan du colis) appartient à l’équipe logistique, et les campagnes publicitaires Facebook appartiennent au marketing. J’ai travaillé assez près des deux bouts de la boucle pour l’expliquer du premier clic de l’acheteur sur une publicité, en passant par la vitrine, l’appel de confirmation et la livraison, jusqu’à l’événement Pixel et la campagne suivante. Cette boucle complète est dessinée plus bas.
L’ancien système de templates a disparu ; tout passe par un seul moteur de thèmes. 11 thèmes, 10 préréglages sectoriels (mode, cosmétique, électronique, mobilier, …), brouillon et publication, et une révision prise avant chaque publication : une mauvaise version est à une restauration près. La vitrine s’affiche de droite à gauche en arabe.
Seule la page d’accueil est pilotée par le moteur. Produit, panier et paiement restent des pages fixes : le vendeur peut refaire la devanture sans casser la caisse.
Produits, variantes, catégories, codes numériques (à usage unique), écran d’inventaire avec seuil d’alerte, corbeille avec purge. Les coupons sont en pourcentage ou en montant fixe, avec plafond, panier minimum, fenêtre de dates et limites par téléphone ; l’utilisation se fait sous verrou de ligne avec une clé d’idempotence. Paliers de quantité, packs et 1 acheté / 1 offert vivent à côté.
La plupart des commandes sont en COD : la première question est de savoir si l’acheteur est réel. Chaque commande reçoit un score de risque de 0 à 100 (historique colis de l’acheteur chez tous les marchands, commandes par téléphone et par jour) ; les commandes risquées sont retenues. Un manager assigne la file, chaque agent travaille la sienne : appel, confirmée / injoignable / refusée, notes, rappels. Chaque transition est un OrderEvent : le journal répond à « qui a fait quoi, quand ».
Les accès sont explicites : rôles owner et member, quatre droits boutique (catalogue, commandes, vitrine, stats), et un rôle d’agent de confirmation qui ne peut que gérer les commandes.
Chaque boutique peut connecter un Pixel Meta et l’API de conversions. Navigateur et serveur envoient le même event_id pour que Meta dédoublonne ; les données acheteur sont hachées en SHA-256, le token est stocké chiffré et chaque envoi est journalisé. Un flux catalogue, des pixels TikTok et GA4, et des relances WhatsApp optionnelles pour les paniers abandonnés complètent le tableau. Pour être clair sur le périmètre : c’est du tracking et de la récupération, pas un gestionnaire de campagnes publicitaires.
Une fois la commande confirmée, elle entre dans le réseau de livraison d’IntiGo : un colis est créé avec un COD égal au total de la commande, le chauffeur livre, et la page commande affiche le statut réel du colis. L’acheteur suit via un lien à jeton. Séparément, la logistique peut envoyer un message WhatsApp Confirmer / Annuler au premier scan du colis (mode souple ou strict, sans jamais bloquer le colis en attendant). Je n’ai pas construit ce côté, mais je sais comment il fonctionne de bout en bout, et c’est ce qui fait du bureau de confirmation humain avant l’expédition et de la validation WhatsApp après le premier scan deux filets de sécurité distincts.
Le module est sur staging avec un soft launch derrière une allowlist ; je ne revendique pas de trafic de production. Les manques que je suis ouvertement : le paiement en ligne (COD uniquement), l’historique des mouvements de stock, et quelques compteurs à durcir. La suite de tests est le filet de sécurité — environ 1 200 fonctions de test sur le code boutique, thèmes, coupons, produits et Meta.
Je suis reconnaissant pour cette expérience : elle m’a permis de suivre une commande tout le long du circuit, de la vitrine vue par l’acheteur jusqu’à la livraison, puis de revenir à Facebook et au marketing qui amène l’acheteur suivant.
Le vendeur envoie les photos d'un premier produit, sa description et son prix. L'assistant prépare un brouillon complet en une dizaine de minutes. Ce n'est pas un générateur de code : c'est plus simple pour nos clients, parce que le résultat reste une boutique valide qu'ils savent déjà modifier.
Photos d'un premier produit, sa description et son prix, écrits ou collés.
Un modèle de vision lit les photos et les faits fournis.
Nom, couleurs, textes en français et en arabe, sections, logo, bannières. Du JSON, jamais du HTML.
Champ par champ : un champ invalide est abandonné, jamais une exception.
Par les services du moteur de thèmes, avec un instantané de l'état en ligne avant toute écriture.
Dans le constructeur, avec un assistant de chat dont chaque outil est validé de la même façon.
Seul le vendeur publie. L'assistant ne publie jamais.
Les outils qui génèrent du code, comme Lovable, remettent à l'utilisateur un projet à comprendre et à maintenir. Ici, le modèle remplit un moteur de boutiques fixe et validé : le vendeur obtient une boutique, pas une base de code. La contrainte est voulue. Pour un commerçant, une boutique qui fonctionne en dix minutes vaut mieux qu'une liberté illimitée, et pour nous, un format fermé se teste, se plafonne et se corrige.
Deux chemins, le même résultat : « Avec l'IA » (environ 10 minutes, rien n'est publié sans le vendeur) ou « Manuellement » (cinq étapes guidées, environ 45 minutes, une vidéo par étape).
L'assistant IA lui-même est le travail d'un collègue. Ce que j'ai construit, c'est le moteur qu'il pilote : sections, réglages, préréglages sectoriels, brouillons et révisions de publication. L'assistant fonctionne parce que ce moteur est déclaratif. Je l'ai ensuite intégré au back-office vendeur et fusionné dans staging.
Pas de HTML, pas de CSS, pas de gabarit : seulement du JSON conforme à un schéma. Le résultat est donc toujours une boutique valide, modifiable dans le même constructeur.
Sections, réglages, textes et produits attendent le « Publier » du vendeur. Un instantané est pris avant chaque écriture, donc on revient en arrière.
Les visuels produit sont retouchés à partir de la photo du vendeur, jamais inventés. Les chiffres d'une infographie viennent du texte du vendeur : le modèle n'a pas le droit d'en inventer.
Plafonds par boutique et par jour (générations, messages, images), file d'images avec quota global par minute, nouvelle tentative sur limite de débit.
Sans clés ou si l'assistant est désactivé, seul le parcours manuel est proposé. Les deux chemins mènent au même résultat et on peut changer d'avis sans rien perdre.
Lecture des captures ci-dessus, du point de vue d'un ingénieur : ce que l'écran montre, puis pourquoi il est construit ainsi. Les chiffres viennent d'une boutique de test sur staging, pas de la production.
« À faire maintenant » : 64 commandes à confirmer, 2 produits à racheter dont 1 en rupture, 1 panier à relancer sur WhatsApp. Trois cartes, un chiffre et un bouton chacune.
La page répond d'abord à « que dois-je faire maintenant ? » puis à « comment ça va ? ». Chaque carte est une file de travail et non un graphique : l'unité est une décision. Se limiter à trois cartes évite qu'elles se concurrencent.
« Démarrer ma boutique » : 9 étapes sur 17, anneau à 53 %, prochaine étape en 1 minute (vérifier l'e-mail) avec « Commencer » et « Vidéo », puis les trois suivantes. Le même 53 % reste dans la barre du haut.
Une seule prochaine étape, chiffrée en minutes, avec une vidéo : on combat la page blanche. L'indicateur persistant dans la barre du haut rappelle l'objectif sur toutes les pages sans occuper l'écran.
261 visites, 361 vues produit, 5 commandes, 0 livrée. Conversion 1,9 % « 5 commandes / 261 visites ». Taux de livraison et de retour affichés « — » avec « 0 livrées · 0 en cours ».
Chaque taux affiche son numérateur et son dénominateur, donc le vendeur peut le vérifier. Quand il n'y a rien à mesurer, on affiche « — » et non 0 %, qui ressemblerait à un échec.
Sur la page Confirmation : « Taux de confirmation » 20 % (1 confirmée sur 5 reçues) et « Taux sur commandes traitées » 100 % (confirmées / confirmées + annulées), avec la formule en pied de page.
Le taux sur commandes traitées mesure la qualité des agents ; le taux sur commandes reçues mesure le retard. Afficher les deux empêche qu'un 100 % flatteur cache une file qui s'allonge.
Groupes : Assistant IA, Commandes (64), Équipe de confirmation, Mes produits (2 à racheter), Vendre plus (codes promo, offres par quantité, paniers à relancer 1, avis, newsletter, Meta), Ma boutique en ligne, Messages clients, Mes chiffres, Réglages. En haut : bascule Livraison / Ecommerce / Marché Gros.
Le menu suit ce que le vendeur veut faire (confirmer, vendre plus, regarder ses chiffres), pas la structure de la base. Les badges reprennent les chiffres des cartes d'action, donc les nombres concordent. La bascule du haut met trois activités dans un seul portail et un seul compte.
Reçues et confirmées par jour, tableau par agent (confirmées, refusées, injoignables, appels, taux, délai moyen 41 min, en cours) et motifs de refus (vide : « Aucun refus enregistré avec un motif »).
Le responsable voit qui confirme, à quelle vitesse et pourquoi les clients refusent, ce qui permet d'améliorer le script d'appel. Les appels viennent du journal : un appel est compté quand l'agent touche « Appeler ».
Boutique de test, 13 sept. au 12 oct. 2026. Les barres sont linéaires : la chute entre visites et commandes est normale sur des données de test, et c'est le format (numérateur et dénominateur affichés) qui compte ici.
Une commande fait un tour complet : publicité, vitrine, commande, confirmation, livraison, résultat, puis signaux renvoyés à Meta pour la campagne suivante. Je connais les sept étapes. J'ai construit celles en violet ; les autres sont des systèmes d'autres équipes que je connais bien.
Les campagnes Facebook et Instagram amènent l'acheteur. Je connais cette partie ; les campagnes appartiennent au marketing.
Ce que voit l'acheteur : thème, fiche produit, panier, coupons, arabe et RTL. Le constructeur de vitrine est mon travail.
Commande COD, stock décrémenté, score de risque 0-100 et commandes risquées retenues.
Équipe de confirmation : file par agent, appels, rappels, motifs de refus, journal d'événements. CRM construit par moi.
Création du colis, chauffeur, suivi, validation WhatsApp au premier scan. Système de l'équipe logistique que je connais.
Livrée, refusée ou retournée, et encaissement COD. Je connais ce retour d'information vers le vendeur.
Pixel + API de conversions (event_id dédoublonné), flux catalogue, relances WhatsApp des paniers abandonnés : la boucle revient aux publicités. Intégration construite par moi.
Reconnaissant pour cette expérience : elle m'a fait suivre une commande de la publicité jusqu'à la livraison, puis de retour vers Facebook et le marketing.
Une commande boutique est d'abord confirmée par une équipe humaine ; une fois le colis créé, une validation WhatsApp prend le relais à son premier scan. Deux filets distincts, dans deux systèmes.
Le panier est revalorisé côté serveur, le stock décrémenté par compare-and-swap, le pixel et la CAPI émettent le même event_id.
Score 0–100 (fiabilité de l'acheteur sur l'historique colis tous marchands, commandes par téléphone/jour). Au-dessus du seuil, la commande est retenue.
Un manager assigne, chaque agent travaille sa file : appel, confirmée / injoignable / refusée, notes, rappels. Tout est journalisé dans OrderEvent.
ship_order exige le statut confirmée, verrouille la ligne, crée le colis avec COD = total de la commande, et stocke le NID du colis.
Au premier scan physique, le template Confirmer / Annuler part vers l'acheteur (mode soft ou strict). Pas de réponse : livraison par défaut.
La page commande lit le statut réel du colis ; l'acheteur suit via un lien à jeton.