Le code, c'était le plus facile

Il y a un moment sur lequel je reviens souvent.

J'essayais de construire un calendrier. Pas un moteur de planification, pas un système de réservation avec gestion des conflits. Un calendrier. Le truc que toutes les apps ont.

Sur mobile, ça faisait planter l'application. Pas un bug que je pouvais tracer, pas un cas limite que je pouvais contourner en réfléchissant. Ça faisait tomber l'ensemble.

J'ai creusé pendant des jours. J'ai essayé tous les contournements que j'ai pu trouver. J'ai écrit au support de la plateforme. J'ai écrit à d'autres développeurs qui avaient livré sur la même stack. Personne n'avait de réponse, parce qu'il n'y en avait pas.

Alors nous avons livré sans. Une fonctionnalité clé, que des centaines d'applications font sans y penser, et il a fallu retourner voir le métier pour dire que ce n'était pas possible.

Ce n'est pas une phrase qu'on a envie de dire deux fois.

Ça ne s'est jamais joué en un jour

On imagine la décision de quitter le no-code comme un moment unique. Un plantage, une facture, un fondateur qui tape du poing sur la table. Ce n'était pas ça. C'était cinq contraintes qui sont arrivées en même temps.

Le mobile. Le produit vit comme une application web et comme une application mobile native. Ce que la plateforme nous laissait faire en natif était limité, et les performances bougeaient selon l'appareil que l'utilisateur avait en main. L'expérience se dégradait et nous ne pouvions rien y faire depuis là où nous étions.

Les fonctionnalités. Le calendrier était le cas le plus net, ce n'était pas le seul. Des choses qui auraient dû être ordinaires devenaient des négociations.

Le coût. La facture n'était pas insoutenable. Elle était visible. Et une fois qu'on la regarde, on s'aperçoit qu'on n'a aucun levier dessus. Posséder sa stack, c'est posséder la capacité de la rendre moins chère.

Une roadmap qui n'était pas la nôtre. Nous avons commencé à douter que la plateforme livre ce dont les développeurs avaient besoin, assez vite, pour nous permettre de construire ce que nous voulions construire.

La propriété. Quand le code est à vous, vous possédez un actif. Ça compte pour vous, et ça compte pour tous ceux qui regardent l'entreprise de l'extérieur.

Aucune de ces raisons ne justifie à elle seule de reconstruire un produit en production. Ensemble, si.

L'outil ne s'est pas dégradé. C'est la ligne qui a bougé.

J'ai passé six ans sur Bubble. Je le défends, et je veux être précis sur les raisons.

C'est rapide. L'éditeur visuel est vraiment bon, la base de données est simple à manipuler, et quand on maîtrise l'outil on passe d'une idée à quelque chose devant les utilisateurs dans la journée. On trouve un bug et on le corrige en deux minutes. Cette vitesse n'est pas un argument marketing, elle est réelle, et c'est pour ça que nous avions construit là.

L'argument du no-code a toujours été la vitesse. Cet argument vient de perdre son avance, parce que le code assisté par agents est arrivé et la lui a prise.

C'est la version honnête de ce qui nous est arrivé. Bubble ne s'est pas dégradé. L'alternative est devenue plus rapide, et à partir du moment où l'alternative va aussi vite, tout le reste de la comparaison se met à compter : les performances, la propriété, le coût, et jusqu'où on peut aller avant que l'outil dise non.

Quand partir

Nous sommes partis avant l'été, et c'était un choix délibéré.

La plupart des produits ont une saison où l'activité retombe. Cette fenêtre est la seule chose qu'on ne peut pas fabriquer, et elle vaut la peine d'être attendue. Elle donne à l'équipe la place de faire le travail correctement, plutôt que dans les interstices entre deux incendies.

Une réserve, parce que c'est là que les migrations dérapent. Nous ne refactorisions pas pour refactoriser. Il y avait une raison derrière chaque partie du chantier : les performances, la maîtrise des coûts, la propriété du code, et la capacité à construire des choses que nous ne pouvions pas construire avant. Si vous ne savez pas nommer les vôtres, attendez.

Ce que ça coûte vraiment

C'est la partie que personne n'écrit.

Vous changez la philosophie de votre équipe. Des builders no-code ne sont pas des builders code. Ce n'est pas que l'un vaut mieux que l'autre, c'est que les réflexes sont différents, et il faut accepter cette transition plutôt que faire comme si elle n'existait pas.

Vous changez votre façon de tester. Pas fondamentalement, mais assez pour que les vieilles habitudes ne suivent pas.

Vous perdez de la vélocité sur les petites choses. Un correctif qui prenait deux minutes sur Bubble peut en prendre quinze. L'agent tourne parfois en rond. Il y a un déploiement, un pipeline, une vérification.

Voici le contrepoids honnête : votre utilisateur se moque que vous ayez déployé en deux minutes ou en quinze. Ce que vous gagnez en échange, c'est du process, de la propreté, et le contrôle de ce qui part réellement en production. Et sur tout ce qui n'est pas un correctif de deux minutes, travailler avec des agents donne une vélocité au moins équivalente au no-code, souvent meilleure.

Cet échange vaut la peine d'être fait. Ça reste un échange.

Tout ce qui n'a pas d'écran

Voilà le piège, et c'est celui contre lequel je mettrais un fondateur en garde en premier.

Quand vous reconstruisez un produit, vous pensez au produit. Les écrans, les parcours, ce qu'un utilisateur voit et clique. Tout ça est testé, parce que quelqu'un l'ouvre et le regarde.

Tout le reste bouge aussi, et rien de tout ça n'a d'écran. Personne ne remarque quand ça casse. C'est exactement ce qui rend l'addition si salée : vous ne le découvrez pas le jour de la mise en ligne, vous le découvrez trois semaines plus tard, et le coût est déjà payé.

Voici la surface qu'on oublie.

La mesure. Vos événements analytics, avec leurs noms exacts, parce que les renommer met discrètement fin à votre historique. Vos pixels publicitaires et vos API de conversion. Vos UTM et votre attribution. Votre bandeau de consentement, et le fait que le tracking respecte réellement ce que l'utilisateur a choisi. Cassez l'un de ces éléments et l'entreprise continue de dépenser en acquisition à l'aveugle, sans que rien ne paraisse anormal de l'extérieur.

Avant de démonter quoi que ce soit, extrayez le plan de tracking. Dans la plupart des boîtes il n'est écrit nulle part. Il vit à l'intérieur de l'ancien outil, et il part avec lui.

Tout ce qui envoie. Les emails transactionnels d'abord : inscription, confirmation, réinitialisation de mot de passe, factures, notifications. Dans une stack no-code ils vivent souvent dans la plateforme, ce qui veut dire que les templates, le branding, les variables et le domaine d'envoi s'en vont avec elle. Puis la partie qu'on découvre trop tard : la réputation d'expéditeur. Nouveau prestataire, nouveau domaine ou nouvelle IP, aucun historique, et vos réinitialisations de mot de passe atterrissent en spam. Vérifiez SPF, DKIM et DMARC avant la bascule, pas après.

Le push mobile est un piège à lui seul. Les tokens et les certificats sont liés à l'identité de l'application. Changez la mauvaise chose et vous perdez toute votre audience push en une seule release.

Les comptes et l'argent. Migrer des utilisateurs veut dire migrer des mots de passe hachés et des sessions, parce que vous n'avez le mot de passe de personne en clair et que vous ne devriez pas vouloir l'avoir. Le login social implique de nouvelles URI de redirection. Les paiements impliquent des abonnements déjà en cours, des webhooks qui pointent vers une ancienne URL, et une numérotation de factures qui doit continuer plutôt que repartir de zéro, ce qui est une question comptable avant d'être une question technique.

Et une décision produit se cache là-dedans : le jour de la bascule, est-ce que tout le monde est déconnecté ? Décidez-le, ne le découvrez pas.

Les liens, y compris ceux déjà dans la nature. Les URL que vous changez sont des URL que vous perdez, donc les redirections ne sont pas optionnelles. Sitemap, balises canoniques, robots. Et chaque lien déjà envoyé par email, publié quelque part, ou ouvert comme deep link mobile doit continuer d'atterrir sur quelque chose.

Le mobile ajoute une contrainte que rien d'autre n'a : vous ne livrez pas une application native au moment qui vous arrange. La revue des stores prend des jours et peut dire non. Et après la mise en ligne, d'anciennes versions restent en circulation pendant des mois, parce qu'une grande part des utilisateurs ne met jamais à jour. Votre backend sert les deux, que vous l'ayez prévu ou non. La mise à jour forcée se construit avant d'en avoir besoin.

Les gens qui ne sont pas vos utilisateurs. Le back-office interne a une équipe ops derrière lui et personne ne la défend. Les outils de support portent un historique de conversations indexé sur des identifiants utilisateurs. Les intégrations sortantes, les automatisations et les webhooks alimentent le travail d'autres équipes. Quelque part, il y a un rapport que quelqu'un ouvre tous les lundis matin, et il cassera sans un bruit.

Le juridique. Vos CGU et votre politique de confidentialité nomment en général vos sous-traitants. Nouvelle stack veut dire nouveaux sous-traitants, ce qui veut dire que ces documents sont désormais faux. L'export et la suppression des données doivent continuer de fonctionner, parce que quelqu'un peut le demander demain.

Et celui qui piège tout le monde. Les plateformes no-code vous donnent un peu de monitoring gratuitement, donc vous n'avez jamais eu à y penser. En code vous partez de rien, et le monitoring est typiquement le genre de chose qu'on repousse à la fin puis qu'on oublie. Mettez-le en place avant la bascule, pas après. Tout l'enjeu est d'apprendre un problème de production par un tableau de bord plutôt que par un utilisateur en colère.

Rien de tout ça n'est glorieux, et rien de tout ça n'est optionnel. Faites la liste avant de commencer. Ce qui n'est pas sur la liste ne sera pas testé, et ce qui n'est pas testé échouera en silence.

La partie dont personne ne parle

Cinq semaines, presque en continu. Application web, mobile natif, aucune interruption de service.

Le code, c'était le plus facile.

Le difficile, c'était la QA, et j'entends quelque chose de précis par là. Dans une migration, la QA n'est pas une étape à la fin. C'est un état qu'on tient du premier jour au dernier, et c'est ce qui décide si vos utilisateurs remarquent quoi que ce soit.

Un scénario par parcours utilisateur, c'est le plancher, pas le plafond. Tester un parcours de bout en bout, c'est bien. Ce n'est pas suffisant. Il vous faut la liste des parcours, écrite, avant de commencer.

Tout ce qui contient un algorithme mérite ses propres scénarios. Un par jeu de variables significatif. Vous ne testez pas que ça fonctionne. Vous testez que ça ne bloque sur aucune combinaison qu'un utilisateur peut réellement produire.

Les formats de données cassent en silence. Les dates avant tout. Les formats ISO sont l'endroit où les choses se passent mal sans que personne ne le voie, ce qui est exactement le type de panne qui coûte le plus cher.

Testez sur quelque chose qui ressemble à la production. C'est le point que je garderais si je ne devais en garder qu'un. Dans la plupart des entreprises, la base de développement ne ressemble pas du tout à la vraie. Elle est plus petite, plus propre, plus rapide. Donc tout fonctionne, on se sent bien, et on met en ligne pour découvrir ce que fait le vrai volume sur une page mal paginée. Si vous voulez savoir si votre produit fonctionne, vous devez le mettre en conditions de production. Sinon vous ne testez pas votre produit, vous testez une démo de votre produit.

Retestez tout après chaque correctif. Un parcours vert lundi n'est pas vert vendredi. Quelqu'un a touché au code entre-temps. Reprenez les scénarios et rejouez-les, tous, à chaque fois.

Rien de tout ça n'est astucieux. C'est de la rigueur, et la rigueur coûte cher parce qu'elle demande de la préparation avant et de la discipline après. Écrire des scénarios de QA utilisables est un vrai travail. Les tenir quand le calendrier vous pousse est plus dur encore.

Le principe en dessous est simple. Nous essuyons les plâtres pour que l'utilisateur ne les essuie pas. Un test ne coûte presque rien. Un utilisateur qui trouve votre bug coûte beaucoup plus, et vous ne choisissez pas le moment où il le trouve.

Ce que j'ai fait, précisément

Je veux être précis ici, parce que la partie intéressante n'est pas celle qu'on attend.

Je n'ai pas écrit l'essentiel de la migration. Un développeur l'a fait.

Ce que j'ai tenu, c'est tout ce qu'il y a autour. Le cadrage produit. Des tickets spécifiés de façon qu'un agent ne puisse pas raisonnablement les mal lire. Un framework, des guidelines, un ensemble de pratiques dans lequel tout le monde travaillait. Une architecture de dépôt assez fragmentée pour que plusieurs agents puissent travailler en parallèle sans se contredire dans le code. Et ensuite la QA, de la première tranche jusqu'à la production.

C'est ça, l'argument pour ce rôle, et c'est pour ça que je pense qu'il compte.

Une équipe qui migre n'a pas besoin d'un développeur de plus. Elle a des développeurs. Ce qu'elle n'a en général pas, c'est une personne qui tient la boucle entière : celle qui décide ce qui se construit, qui l'écrit de façon qu'on ne puisse pas le mal lire, qui regarde ce qui revient, et qui refuse de faire confiance à un feu vert que personne n'a mérité.

Quand l'équipe est petite, cette personne développe aussi. Quand l'équipe est plus grande, elle soutient les développeurs et consacre le temps libéré à ce que tout le monde dépriorise, c'est-à-dire la preuve.

Dans les deux cas c'est un seul rôle, et c'est celui qui décide si la migration est une réussite ou une histoire qu'on raconte avec précaution.

Ce que ça a donné

Nous l'avons menée à terme. Application web, mobile natif, aucune interruption de service, cinq semaines.

Pas parce que nous avons écrit du code vite. Parce que nous savions ce que nous construisions, que nous l'avons écrit d'une façon qu'un agent ne pouvait pas mal lire, et que nous avons refusé de croire quoi que ce soit que nous n'avions pas vu fonctionner en conditions réelles.

Si vous regardez votre propre plateforme en vous demandant si c'est votre tour, voilà le vrai test. Pas de savoir si le no-code est encore assez bien. De savoir si vous pouvez encore construire ce que vous avez besoin de construire, et si vous pouvez prouver que ça marche au moment où ça compte.

Si c'est votre tour

Commencez par la liste. Écrivez tout ce qui, dans votre produit, n'a pas d'écran : le tracking, les emails, les paiements, les liens déjà dans la nature, les rapports que personne ne revendique. Cette liste vous en dira plus sur la taille du chantier que n'importe quel audit technique.

Le reste de ma façon de travailler est dans un playbook. Dix-sept chapitres, gratuit, sans email à donner. Des specs qu'un agent ne peut pas mal lire, une QA qu'on peut tenir quand le calendrier pousse, et la discipline qui rend la construction avec des agents sûre et pas seulement rapide.

Et si c'est vous qui devez mener la migration, quelques questions nous diront à tous les deux si ça vaut le coup d'en parler. Je vous le dirai franchement si ce n'est pas le cas.