Développement e-commerce : un socle qui suit, au lieu de freiner
Correctifs, évolutions, intégrations, migrations : chaque chantier est chiffré en ce qu'il vous coûte aujourd'hui avant d'être chiffré en jours de travail.
Vos développements avancent, votre business ne le sent pas
Trois mécaniques de dette que nous retrouvons dans presque tous les sites que nous reprenons.
Chaque évolution attend son tour, et chaque ticket se facture
Le prestataire est pris ailleurs, la TMA coûte cher, et les demandes s'empilent. Entre l'idée et sa mise en ligne, des semaines passent, et l'envie de demander finit par passer aussi.
Personne ne chiffre ce que rapporte un développement
Sans vue sur votre business, tous les chantiers se valent : le prestataire exécute la liste dans l'ordre où elle arrive, sans conseiller ce qui devrait passer devant, et sans rien proposer de lui-même.
Le e-commerce demande plus que du code
Une donnée à exploiter sérieusement (BigQuery), un ERP, un CRM, des flux : autant de ponts que votre boutique exige et qu'un développeur web seul ne construit pas.
Cinq chantiers, un seul objectif : que la technique cesse de décider
Du correctif de la semaine à la migration de plateforme, la même équipe tient le socle et sait ce que chaque chantier débloque commercialement.
Développement e-commerce, sur la plateforme que vous avez déjà
Fonctionnalités, gabarits, tunnel de commande, interfaces d'administration, sur Shopify, PrestaShop, WooCommerce, Magento, Salesforce Commerce Cloud et les stacks sur mesure. Le code livré est documenté pour être repris par quelqu'un d'autre : c'est ce qui le garde vraiment vôtre.
Intégration ERP, PIM et logistique
Votre système de gestion, votre catalogue et votre préparation de commandes connectés à la boutique, dans les deux sens. Stocks, prix, fiches et statuts d'expédition circulent seuls : un écart déclenche une alerte, et chaque flux a sa reprise sur erreur.
TMA e-commerce, correctifs et évolutions
La maintenance applicative de votre boutique : anomalies, montées de version, dépendances, sauvegardes vérifiées. Le journal des interventions reste ouvert et lisible : vous savez ce qui a été touché, et pourquoi.
Migration de plateforme sans perte de référencement
Changer de plateforme, ou monter de version majeure sur la même. Catalogue, clients, commandes, historique, et surtout le plan de redirections écrit page par page avant la bascule, avec le relevé des positions et du trafic pris avant de commencer.
Core Web Vitals et vitesse de chargement
La vitesse est mesurée sur le terrain, chez vos vrais visiteurs et sur leurs vrais appareils, pas en laboratoire. Nous visons les seuils que Google publie dans sa documentation Core Web Vitals, 2,5 secondes pour le LCP et 200 millisecondes pour l'INP, et nous chiffrons ce qu'ils coûtent à atteindre.
Nous chiffrons ce que le problème coûte avant de chiffrer sa correction
Quatre temps propres au socle technique. Le dernier dit ce que nous ne ferons pas.
Ce que la panne coûte par mois
Un pas de tunnel qui échoue, une rupture vendue, une page trop lente sur mobile : chaque panne a un coût mensuel calculable, et c'est lui qui classe les chantiers, pas l'ordre d'arrivée.
Nous lisons le code avant de proposer de le remplacer
Ce qui sert, ce qui est mort, ce qui est risqué à toucher. Sans cette carte, une refonte est un devis, pas un diagnostic.
Rien ne part en production sans chemin de retour
Chaque mise en ligne a son retour arrière écrit avant, et sa vérification après. Un correctif qui ne peut pas être annulé est un pari.
Ce que nous refusons de faire
Pas de refonte quand trois correctifs suffisent, pas de module pour compenser un module mal configuré, pas de migration sans plan de redirections, et aucun chantier sur une plateforme que nous ne saurions pas tenir ensuite.
Un chantier technique se juge sur ce qu'il débloque
Cette page n'affiche aucun chiffre de résultat, et c'est volontaire : aucun de nos cas publiés ne porte de chiffre attribuable au socle technique. Voici les indicateurs sur lesquels nous jugeons un chantier, avant et après.
Le taux d'échec du tunnel, pas à pas
La part de paniers qui se perd à chaque étape technique, relevée avant et après correction. C'est l'indicateur qui transforme un bug en euros.
L'écart de stock
Le nombre de références dont la quantité diffère entre le système de gestion et la boutique, et le nombre de commandes annulées qui en découlent.
La vitesse mesurée sur le terrain
LCP et INP relevés chez vos visiteurs réels, sur la période, pas sur un test unitaire depuis un poste de bureau.
La part de commandes traitées sans reprise manuelle
Combien de commandes vont de la boutique à l'expédition sans qu'une personne recopie quelque chose.
Les positions et le trafic conservés après migration
Relevés avant la bascule, comparés après, page à page. C'est le seul chiffre qui dit si une migration s'est bien passée.
Le nombre d'interventions correctives récurrentes
Une anomalie qui revient trois fois n'est pas un incident, c'est une cause qui n'a pas été traitée.
de commandes perdues au tunnel en moins, après correction des erreurs de paiement et des temps de chargement
du trafic organique conservé le mois suivant la migration
Ce qui reste entre vos mains
Le code, les accès et la documentation sont à votre nom, et pensés pour qu'un autre prestataire puisse reprendre sans repartir de zéro.
La cartographie de l'existant
Ce qui compose votre site aujourd'hui, module par module, flux par flux. Ce qui sert, ce qui ne sert plus, ce qui est risqué à toucher et pourquoi.
Le code livré, et sa documentation
Versionné, commenté aux endroits qui le méritent, avec la procédure de mise en ligne. Lisible par quelqu'un d'autre que nous, c'est la condition pour qu'il reste le vôtre.
Les connecteurs et leur journal
Les flux entre la boutique et vos outils de gestion, avec ce qui se passe quand un flux échoue, et où le voir.
Le plan de migration et son registre de redirections
Chaque ancienne adresse et sa destination, plus le relevé de référence pris avant la bascule pour pouvoir comparer après.
Le journal des interventions
Ce qui a été touché, quand, et pourquoi. Vous le lisez sans nous le demander, et vous y retrouvez la cause d'un changement plutôt que sa date.
Le relevé de performance avant et après
Les mêmes mesures, sur le même périmètre, aux deux dates. Un chantier de vitesse sans relevé de départ n'est pas vérifiable.
Ce que les marques nous demandent sur leur socle technique
Comment se passe une migration de PrestaShop vers Shopify ?
Par un inventaire avant tout le reste : ce que le site fait aujourd'hui et que la nouvelle plateforme ne fera pas nativement. C'est là que se trouvent les vraies surprises, pas dans le transfert du catalogue. Ensuite viennent la reprise des données, le plan de redirections adresse par adresse, et une période où les deux environnements sont comparés avant la bascule. Les migrations qui se passent mal sont presque toujours celles qui ont commencé par le design.
Peut-on refondre son site sans perdre son référencement ?
Oui, à condition de prendre le relevé de départ avant de commencer : les adresses qui reçoivent du trafic, les positions, les pages qui vendent. Le plan de redirections se construit à partir de cette liste, pas à partir de l'arborescence rêvée. Une baisse est normale les premières semaines ; ce qui n'est pas normal, c'est de ne pas pouvoir dire de combien.
Que couvre exactement une TMA e-commerce ?
La maintenance applicative de votre boutique : anomalies, montées de version, dépendances et sauvegardes vérifiées, plus les évolutions courantes. Ce n'est pas une astreinte, et ce n'est pas une régie de développement à volume libre. Le périmètre est écrit, et ce qui en sort est arbitré comme un chantier, avec son coût d'inaction.
Faut-il connecter son ERP à sa boutique en ligne, ou continuer à exporter ?
L'export tient tant que le catalogue est petit et que les prix bougent peu. Le basculement se voit à deux signaux : le temps qu'une personne passe à recopier, et le nombre de commandes annulées pour rupture. Quand l'un des deux devient chiffrable, le connecteur coûte moins cher que la situation actuelle, et le calcul se fait avant de décider.
Faut-il refaire le site, ou le réparer ?
Le réparer, dans la grande majorité des cas que nous ouvrons. Une refonte remet à zéro ce qui marchait aussi, et elle repousse de plusieurs mois les correctifs qui rapportaient tout de suite. La refonte devient la bonne réponse quand la plateforme ne reçoit plus de correctifs de sécurité, ou quand la moitié du temps de chaque évolution passe à contourner l'existant.
Comment améliorer ses Core Web Vitals sur un site e-commerce ?
En commençant par mesurer sur le terrain plutôt qu'en laboratoire : les deux ne donnent pas le même diagnostic, et seul le terrain compte pour vos acheteurs. Sur un site marchand, l'essentiel se joue presque toujours au même endroit, les images du catalogue et les scripts tiers accumulés au fil des années. Ce sont deux chantiers concrets, pas une réécriture.
Et si nous regardions vos chiffres ensemble ?
Le premier appel est un diagnostic, pas un argumentaire de vente. Montrez-nous votre liste de chantiers en attente, nous vous dirons ce que chacun vous coûte tant qu'il attend.
Les projets qui dérapent ont presque tous dérapé avant le développement.
Un tunnel corrigé qui n'envoie rien à la mesure reste invisible dans vos arbitrages.
Comment un périmètre se cadre, et ce qui est écrit avant que le premier chantier démarre.
Vous êtes une agence ? Nous produisons ces développements pour votre compte, en marque blanche. Voir ce que nous produisons pour les agences