Votre application tourne. Mal, mais elle tourne.
Elle rame aux heures pleines. Chaque correction en casse deux ailleurs. Le développeur qui l'a construite n'est plus joignable, et personne chez vous ne sait vraiment comment elle fonctionne à l'intérieur.
Vous n'avez pas un problème de logiciel. Vous avez un problème de fondations.
Cet article ne va pas vous rassurer. Il décrit ce qu'on trouve réellement quand on ouvre le capot d'une application d'entreprise reprise à un autre prestataire, et comment on décide de réparer ou de reconstruire.
Onze questions pour savoir où vous en êtes
Répondez honnêtement. Chaque « oui » est un symptôme, pas une condamnation. Prenez vingt minutes, ouvrez votre éditeur, vérifiez pour de vrai. Les réponses au jugé ne servent à rien. Les six premières se contrôlent sans aucune compétence technique.
1. Votre base d'utilisateurs est-elle exposée publiquement ?
C'est la première chose à vérifier, la plus vite faite, et la plus grave quand la réponse est mauvaise.
Bubble propose une porte d'entrée sur vos données, la Data API. Elle est utile : c'est elle qui permet à votre application de dialoguer avec vos autres outils. Mal réglée, elle laisse n'importe qui consulter vos tables depuis l'extérieur, sans être connecté.
Le test, en deux minutes. Ouvrez un onglet de navigation privée et appelez cette adresse, en remplaçant le nom par le vôtre :
https://votreapp.bubbleapps.io/api/1.1/meta/swagger.json
Si votre application est branchée sur votre propre nom de domaine, c'est https://votredomaine.com/api/1.1/meta/swagger.json.
Cette adresse liste tout ce que votre application expose au monde extérieur : les types de données accessibles et les traitements déclenchables. Si vous y voyez apparaître user, poussez d'un cran :
https://votreapp.bubbleapps.io/api/1.1/obj/user
Si des adresses e-mail, des noms ou des numéros de téléphone s'affichent, votre base d'utilisateurs est publique. N'importe qui peut l'aspirer en une commande.
Ce qu'il faut comprendre, et qui n'est pas intuitif : exposer un type de données et le protéger sont deux réglages différents. Cocher « exposer » dans les paramètres ne demande pas si les données doivent être lisibles. Ce sont les règles de confidentialité, définies table par table, qui décident. Beaucoup d'applications ont été construites avec l'exposition activée « pour tester une intégration » et les règles de confidentialité laissées en l'état. Le test est resté en production.
C'est le défaut le plus fréquent que nous rencontrons en reprise. Ce n'est pas un détail technique : c'est de la donnée personnelle accessible, avec ce que ça implique en cas de contrôle ou de plainte.
2. Une de vos tables dépasse-t-elle 50 champs ?
Petit détour de vocabulaire, parce que la suite en dépend.
Une table est une catégorie d'information : les clients, les commandes, les produits, les inscriptions. Un champ est une case dans cette catégorie : le nom, la date, le montant, le statut. L'ensemble forme votre base de données, c'est-à-dire la façon dont votre application range ce qu'elle sait.
Vous les trouvez dans l'onglet Data de l'éditeur Bubble, section Data types. Cliquez sur une table, comptez les lignes. Personne n'a besoin d'être développeur pour faire ça.
Au-delà d'une cinquantaine de cases pour une seule catégorie, il s'est presque toujours passé la même chose : plusieurs concepts métier ont été empilés au même endroit, faute d'avoir été séparés au départ. La table « client » contient les informations du client, mais aussi celles de ses contrats, de sa facturation, de son historique, plus trois indicateurs calculés et deux champs abandonnés que personne n'ose supprimer.
Chaque lecture devient plus lourde. Chaque évolution devient plus risquée, parce qu'on ne sait plus qui dépend de quoi.
3. La table User dépasse-t-elle 15 champs ?
Même symptôme, conséquence bien plus lourde. C'est la question la plus sous-estimée de la liste.
La table User est la plus sollicitée de toute votre application. Dès qu'un écran affiche quoi que ce soit lié à la personne connectée, il la relit. Chaque page, chaque vérification de droits, chaque affichage conditionnel passe par elle. Ce qu'on lui ajoute se paie donc partout, tout le temps, sur tous les écrans.
C'est aussi la table la plus tentante à gonfler : on y met le rôle, puis les préférences, puis l'adresse, puis les compteurs, puis l'historique. Chacun de ces ajouts semble anodin isolément. Cumulés, ils alourdissent chaque chargement de votre application.
4. Avez-vous plus d'une vingtaine de tables ?
Ce n'est pas un défaut en soi. Une activité complexe a besoin de beaucoup de catégories, et une école qui gère cursus, élèves, inscriptions, paiements et professeurs en aura légitimement plus de vingt.
Mais combiné aux deux questions précédentes, c'est le signe d'une structure qui a grossi par ajouts successifs sans jamais avoir été reprise dans son ensemble. Beaucoup de tables et des tables obèses, c'est le portrait type d'une base qui décrit l'histoire de l'application au lieu de décrire le métier.
5. L'application est-elle lente ?
Pas « parfois, quand il y a du monde ». Lente au quotidien, sur les écrans que vos équipes utilisent tous les jours, au point qu'elles ont pris l'habitude d'attendre et ne le signalent même plus.
La lenteur n'est presque jamais un problème de serveur. C'est un problème de conception : un écran qui charge la table entière pour afficher dix lignes, un calcul refait à chaque affichage au lieu d'être stocké, une liste qui interroge la base une fois par élément affiché.
Le test simple : chronométrez l'écran le plus utilisé de votre application, à deux moments différents de la journée. Si vous dépassez trois secondes, ce n'est pas une impression.
6. Quand votre développeur corrige un bug, en apparaît-il de nouveaux ?
C'est le symptôme le plus révélateur de tous, et celui que vous pouvez constater sans rien ouvrir.
Une application saine est faite de morceaux indépendants : on en change un sans toucher aux autres. Quand une correction en casse deux ailleurs, c'est que tout est lié à tout, et qu'aucun test automatique ne surveille l'ensemble.
À ce stade, le coût de chaque évolution augmente au lieu de diminuer. C'est la définition même de la dette technique en train de courir. Regardez vos douze derniers mois de maintenance : si la facture monte alors que l'application ne change pas, vous payez des intérêts.
7. Sur quel plan êtes-vous, et pour combien d'utilisateurs ?
Bubble facture par paliers, avec une monnaie interne appelée workload units, des unités de consommation. Au moment où nous écrivons, les plans payants sont Starter (29 $ par mois, 175 000 unités), Growth (119 $ par mois, 250 000 unités), Team (349 $ par mois, 500 000 unités), puis Enterprise sur devis.
Deux erreurs symétriques, et nous les voyons aussi souvent l'une que l'autre.
Payer Growth pour une application qui ne bouge plus. L'application est en production, stable, avec une poignée d'utilisateurs quotidiens. Personne ne développe dessus depuis un an. Le plan a été souscrit pendant la construction et n'a jamais été revu. Vous payez quatre fois le prix nécessaire.
Rester sur Starter alors que quelqu'un développe encore. C'est l'erreur coûteuse, et elle est moins visible. Le contrôle de version arrive à partir de Growth. C'est la possibilité de travailler sur une branche séparée, de revenir en arrière, et de déployer quand c'est prêt. Sur Starter, votre développeur travaille beaucoup plus près de ce que voient vos utilisateurs, sans filet pour revenir en arrière proprement. Sur une application en production avec de vrais clients dessus, c'est un risque qui ne vaut pas les 90 $ d'écart mensuel.
La règle est simple : si quelqu'un développe encore sur votre application en production, Growth n'est pas un confort, c'est une assurance. Si personne n'y touche, descendez.
Et faites le rapport, une fois : ce que vous coûte la plateforme chaque mois, divisé par le nombre de personnes qui s'en servent réellement chaque semaine. Le chiffre est souvent embarrassant.
8. Avez-vous déjà ouvert vos logs ?
Les logs sont le journal d'activité de votre application : ce qui s'est exécuté, quand, et ce que ça a consommé. Vous les trouvez dans l'onglet Logs de l'éditeur.
Presque personne ne les regarde. Ils disent pourtant précisément ce qui consomme des unités, donc ce qui vous coûte. Une seule automatisation mal écrite qui tourne en boucle la nuit, un traitement récurrent oublié après un test, une recherche qui balaie toute la base à chaque appel : ce genre d'anomalie peut représenter une part majeure de votre facture mensuelle sans que personne ne s'en aperçoive, parce que le montant global paraît normal.
Triez par consommation. La ligne du haut vous surprendra.
9. Combien de pages compte votre éditeur ?
Ouvrez la liste déroulante des pages, en haut à gauche de l'éditeur, et comptez.
Un nombre élevé signifie généralement qu'on a dupliqué au lieu de rendre dynamique. Au lieu d'un seul écran « fiche produit » qui s'adapte au produit affiché, on a créé une page par cas. C'est le réflexe naturel de quelqu'un qui débute : c'est plus simple à construire, et ça marche. Au début.
Conséquence directe : chaque modification doit être répétée autant de fois qu'il y a de pages. Une seule oubliée, et vous avez une incohérence que personne ne remarquera avant qu'un client ne la signale.
Le même raisonnement vaut pour les reusable elements, les blocs réutilisables. Une application saine en a : le menu, l'en-tête, les fenêtres de dialogue. Une application qui n'en a aucun a forcément recopié partout.
10. Vos styles sont-ils centralisés ?
Les couleurs, les tailles de texte, les boutons doivent être définis à un seul endroit et réutilisés partout. C'est ce que Bubble appelle les styles.
Le test, en trente secondes. Ouvrez une page, cliquez sur deux ou trois éléments au hasard : un bouton, un titre, un bloc de texte. Regardez le champ Style dans le panneau de propriétés. Si vous lisez « none », l'élément a été mis en forme à la main, isolément. Si vous lisez le nom d'un style suivi de la mention overridden, c'est pire : un style existe bien, mais on l'a contourné localement.
Deux ou trois éléments suffisent à savoir. Si aucun n'utilise proprement un style partagé, changer une couleur de marque devient un chantier de plusieurs jours, écran par écran, avec des oublis garantis. Et le jour où vous refaites votre identité visuelle, on vous annoncera un devis que vous trouverez absurde. Il ne le sera pas.
11. Vos workflows de back-end sont-ils propres ?
Précisons, parce que le terme est flou pour qui ne construit pas d'applications.
Un workflow est une suite d'actions déclenchée par un événement : quand l'utilisateur clique, alors on enregistre, puis on envoie un e-mail. Les workflows de back-end sont ceux qui tournent côté serveur, sans que personne ne les voie : envois d'e-mails différés, calculs nocturnes, synchronisations avec vos autres outils, traitements récurrents.
Ils se trouvent dans la page Backend workflows de l'éditeur. Ouvrez-la et regardez trois choses.
Combien y en a-t-il, et savez-vous à quoi ils servent ? Un workflow dont personne ne sait plus l'usage est un workflow qu'on n'ose pas supprimer, et qui continue de tourner.
Y a-t-il des traitements récurrents actifs ? Ce sont les plus coûteux, et les plus souvent oubliés après une phase de test.
Sont-ils protégés ? Un workflow de back-end exposé sans vérification peut être déclenché de l'extérieur. C'est le prolongement direct de la question 1.
C'est là que se cachent les coûts invisibles et les erreurs silencieuses : une facture qui ne part pas, un statut qui ne se met pas à jour, un e-mail envoyé deux fois. Personne ne le signale avant qu'un client ne s'en plaigne.
Comment lire vos réponses
Un à deux « oui » : votre application a vieilli normalement. Une reprise ponctuelle suffit.
Trois à cinq « oui » : vous avez de la dette technique installée. Elle est encore traitable par corrections successives, mais chaque mois d'attente augmente la facture.
Six « oui » ou plus : votre application n'est pas une application aboutie. C'est un prototype qui a été mis en production et qu'on n'a jamais repris. Ce n'est pas une catastrophe. Nous allons y revenir, parce que c'est même une bonne nouvelle. Mais il faut le savoir avant de dépenser un euro de plus dessus.
Si vous avez répondu oui à la question 1, quel que soit le reste : traitez-la cette semaine. C'est la seule qui vous expose juridiquement.
Dette technique : ce que le terme veut vraiment dire
Le mot circule partout, souvent comme une insulte déguisée. Il désigne pourtant quelque chose de précis, et l'employer correctement change la conversation.
La dette technique, c'est le coût futur des décisions prises pour aller vite aujourd'hui. Exactement comme une dette financière : on emprunte du temps maintenant, on rembourse plus tard, avec des intérêts.
Un exemple, parce que la définition seule ne parle à personne.
Au démarrage, il fallait livrer une première version en six semaines. Pour tenir le délai, le développeur a rangé les informations de facturation directement dans la table des clients, au lieu de créer une table dédiée. C'était le bon arbitrage à ce moment-là : une table de moins à construire, deux semaines gagnées, et le besoin ne dépassait pas une adresse par client.
Deux ans plus tard, un client vous demande de pouvoir facturer sur plusieurs entités. Ce qui aurait pris une journée sur une structure propre en prend huit : il faut créer la table qui manque, déplacer les données existantes sans rien perdre, puis reprendre un par un tous les écrans et tous les traitements qui s'étaient construits par-dessus l'ancien choix. Les intérêts, ce sont ces sept jours.
Trois choses à retenir avant d'aller plus loin.
Toute application en porte. Une application sans dette technique n'existe pas, même bien construite, même récente. Celui qui vous affirme le contraire vend quelque chose.
Ce n'est pas une faute morale. Ce sont des choix qui se comprenaient au moment où ils ont été faits, avec le budget, le délai et l'information de ce moment-là. Juger l'architecture de 2022 avec les besoins de 2026 n'a aucun sens.
Elle se mesure. La bonne question n'est jamais « y en a-t-il ». C'est combien, où, et qu'est-ce que ça coûte de la rembourser. C'est très exactement ce que produit un audit de reprise, et c'est ce qui permet de décider entre réparer et reconstruire.
Ce qu'on trouve, à chaque fois
Trois causes reviennent dans presque toutes les reprises que nous faisons. Elles ne s'excluent pas : le plus souvent, elles se cumulent.
L'application n'a jamais été pensée pour vous
Nous avons repris une application construite en 2022 pour une école d'arts. En l'ouvrant, quatre ans plus tard, une chose est apparue très vite : elle avait été dupliquée depuis celle d'une autre école, puis réadaptée.
Sauf que les deux écoles ne fonctionnaient pas pareil. Pas « un peu différemment » : pas pareil du tout. Les cursus, le calendrier des inscriptions, les modes de paiement, les règles de réduction : rien ne se déroulait dans le même ordre ni selon la même logique. On avait donc plaqué l'organisation d'une structure sur une autre, et comblé les écarts par des contournements successifs.
C'est exactement l'inverse de ce qu'une application métier sur mesure doit produire. Si vous en construisez une, c'est précisément parce que votre entreprise a sa façon de faire, ses exceptions, ses cas particuliers. Ce n'est pas à l'entreprise de s'adapter à l'outil.
Le piège du template mérite qu'on s'y arrête, parce qu'il commence toujours par une bonne idée.
Un template, c'est une application préconstruite qu'on achète quelques dizaines ou quelques centaines d'euros : une place de marché, un outil de réservation, un tableau de bord. Sur le papier, le calcul est imparable. Quelqu'un a déjà fait le travail, les écrans existent, la base de données est en place. Vous économisez des semaines et vous démarrez lundi.
Ce que le calcul oublie, c'est que le template a été conçu pour un cas générique, et que votre entreprise n'en est pas un.
Alors on adapte. Un champ ici, un écran là, une règle de gestion qui n'était pas prévue. Chaque adaptation est raisonnable prise isolément. Mais chacune vous éloigne de la logique d'origine, sans pour autant vous rapprocher d'une logique qui serait la vôtre. Au bout de quelques mois, vous avez perdu la cohérence du template sans avoir gagné celle d'une conception faite pour vous. Vous êtes entre les deux, et c'est l'endroit le plus cher.
Trois conséquences concrètes, que nous constatons à chaque reprise de ce type.
Vous héritez d'une architecture sans son mode d'emploi. L'auteur du template a fait des choix : pourquoi cette table plutôt qu'une autre, pourquoi ce découpage. Ces choix ne sont documentés nulle part. Vous les subissez sans jamais savoir ce qu'ils protégeaient.
Vous ne pouvez plus suivre les mises à jour. Dès que vous avez modifié le template en profondeur, reprendre la version corrigée par son auteur devient impossible. Vous restez sur votre copie, seul, avec ses défauts d'origine.
Le désenchevêtrement coûte plus cher que la reconstruction. C'est le point contre-intuitif, et c'est celui que les dirigeants découvrent trop tard. Séparer ce qui vient du template de ce qui vient de vous demande de comprendre deux logiques au lieu d'une. À partir d'un certain niveau de personnalisation, repartir sur des bases propres est plus rapide que démêler.
Le cas de l'école est la version aggravée de ce piège : ce n'était même pas un template générique, mais l'application spécifique d'une autre organisation, avec sa logique à elle, pensée pour ses contraintes à elle.
Les modules ont été empilés au fil des années
Une fonctionnalité ajoutée la troisième année sur une base conçue la première ne s'intègre pas : elle se greffe.
La première greffe passe sans dommage. La deuxième oblige à contourner la première, parce que la base ne prévoyait ni l'une ni l'autre. La troisième contourne les deux précédentes. Au bout de cinq, plus personne ne sait comment l'information circule dans l'application. Ni le développeur, ni vous, ni vos équipes, qui ont développé leurs propres contournements sans les documenter.
C'est le scénario le plus fréquent chez les entreprises dont l'application a bien vieilli commercialement. L'outil a suivi la croissance, et c'est plutôt bon signe. Le problème n'est pas d'avoir ajouté : c'est que personne n'a jamais eu le mandat de s'arrêter, de reprendre les fondations, et de préparer l'étage suivant avant de le construire.
Un signe qui ne trompe pas : demandez à trois personnes de votre équipe d'expliquer ce qui se passe quand une commande est annulée. Si vous obtenez trois réponses différentes, l'empilement a gagné.
Les fondations ont été posées par quelqu'un qui apprenait
On le voit à des signes constants. Des dizaines de pages là où deux pages dynamiques suffiraient. Des listes traitées élément par élément au lieu d'être manipulées en bloc. Une base de données qui décrit les écrans au lieu de décrire le métier. Des styles jamais centralisés.
C'est fréquent, et compréhensible : les plateformes visuelles ont massivement abaissé le ticket d'entrée, ce qui est leur mérite. Beaucoup d'applications d'entreprise ont été construites par des profils juniors, des freelances en début de parcours ou des dirigeants en autoformation, souvent avec beaucoup d'énergie et peu de recul sur ce qui se passe quand l'usage monte.
Et maintenant la partie que personne ne vous dira, alors qu'elle change tout.
Construire avec un débutant est un choix économique parfaitement défendable. À une condition : savoir dès le départ que ce que vous obtiendrez est un prototype. Pas une version définitive. Un prototype.
Le mot n'est pas péjoratif. Un prototype, c'est un objet qu'on construit pour apprendre. Le vôtre a été utilisé pendant des mois ou des années, par de vraies personnes, sur de vraies données, dans de vraies conditions. Il a été testé et itéré par l'usage lui-même, ce qu'aucun atelier de conception ne saura jamais reproduire.
Alors oui, la version définitive devra probablement être reprise depuis zéro. Et non, cela n'annule rien du travail accompli ni du temps passé. C'est même l'inverse : ce prototype est une mine d'or, et voici pourquoi, très concrètement.
Il a fait remonter vos exceptions. Les cas particuliers qui ne figuraient dans aucun cahier des charges sont apparus tout seuls, parce que la réalité les a imposés. Ils sont là, sous vos yeux, dans les contournements que vos équipes ont inventés.
Il a tranché des questions qu'on aurait mis des semaines à poser. Quel écran est réellement utilisé, lequel ne sert jamais, quelle information manque tous les jours. L'usage a répondu à votre place.
Il transforme la question du cadrage. C'est le gain le plus important, parce que le cadrage est la phase la plus longue et la plus coûteuse d'une construction sur mesure. Sans prototype, on demande à un dirigeant : « de quoi avez-vous besoin ? ». Une question à laquelle personne ne sait répondre entièrement. Avec un prototype, on demande : « qu'est-ce que vous avez fini par faire, et pourquoi ? » C'est une question à laquelle les réponses existent déjà.
Autrement dit : ce que vous avez payé n'a pas servi à obtenir une application. Il a servi à obtenir la spécification de la bonne application. C'est cher pour une spécification, et c'est très bon marché pour trois ans d'expérience utilisateur réelle.
Ce que votre application vous coûte aujourd'hui
Avant de parler budget de refonte, chiffrez l'existant. C'est le calcul que presque personne ne fait, et c'est celui qui décide de tout le reste.
Le temps de vos équipes. Une enquête Bpifrance situe à deux jours par semaine le temps que 28 % des dirigeants de PME passent sur des tâches administratives. Additionnez, pour chaque personne concernée, le temps perdu chaque jour à attendre un écran, ressaisir une donnée qui existe ailleurs, corriger une erreur de saisie. Sur une année, le total descend rarement en dessous d'un mi-temps.
Les corrections. Reprenez ce que vous avez facturé en maintenance sur les douze derniers mois, et regardez la courbe. Si elle monte alors que l'application n'a pas changé de périmètre, ce ne sont plus des corrections : ce sont les intérêts de votre dette technique.
Les erreurs invisibles. Les écarts entre prévisions et réalité atteignent en moyenne 29 % quand le pilotage repose sur des tableurs et des outils mal reliés. Une facture fausse, un stock décalé, un planning incohérent : chacun a un coût réel, et aucun n'apparaît sur une ligne comptable identifiable.
L'abonnement. Votre plan mensuel, rapporté au nombre d'utilisateurs réellement actifs chaque semaine.
Le coût du renoncement. Le plus lourd, et le seul qui ne se facture jamais. Ce sont les évolutions que vous ne demandez plus, les idées que vous n'exprimez même plus en réunion, parce que tout le monde sait que « ça va casser autre chose ». Une application qui bloque vos décisions vous coûte infiniment plus cher que son abonnement.
Additionnez. Vous avez maintenant un chiffre à comparer à un devis. La comparaison devient beaucoup plus simple qu'elle n'en avait l'air.
Réparer ou reconstruire une application métier sur mesure
Il n'y a pas de réponse générale. Il y a une méthode.
Comptez trois semaines à un mois avant toute décision
C'est le temps qu'il faut à un nouveau constructeur pour comprendre la logique de celui qui l'a précédé.
Et il faut dire pourquoi c'est aussi long, parce que la raison est presque toujours la même : neuf fois sur dix, votre application n'a aucune documentation. Pas de schéma de la base de données, pas de note expliquant pourquoi telle table a été découpée ainsi, pas de liste des traitements automatiques, rien sur les zones fragiles. Tout ce savoir vivait dans la tête d'une personne, et cette personne est partie.
Le nouveau constructeur doit donc reconstituer une intention à partir de ses seuls effets. C'est un travail d'enquête : ouvrir chaque écran, suivre chaque enchaînement, comprendre pourquoi ce champ existe alors qu'il n'est affiché nulle part, deviner ce que protégeait ce contournement bizarre.
Beaucoup de clients en reprise refusent cette phase, et l'argument revient toujours dans les mêmes termes : l'application existe, elle fonctionne à peu près, donc tout serait déjà sous nos yeux. C'est faux, et c'est le malentendu le plus coûteux de toute la relation.
Une reprise se comporte comme une pelote de laine. On tire sur un fil pour corriger un premier point, et il en révèle un deuxième, qui en révèle un troisième. On ne découvre le vrai périmètre qu'en tirant. Chiffrer une reprise sans cette phase, c'est annoncer un prix qu'on ne pourra pas tenir, et tout le monde y perd : le client qui se sent trompé, le constructeur qui travaille à perte, et l'application qui reste à moitié réparée.
Un constructeur qui vous chiffre une reprise au forfait, en une heure, sans avoir ouvert l'application, ne vous rend pas service. Il vous vend un devis qu'il devra renégocier.
Si vous restez sur l'existant, travaillez à l'heure
Un volume d'heures fixe par mois, et on avance par petites touches sans casser ce qui tourne.
C'est la voie prudente, et souvent la bonne : votre activité continue pendant qu'on répare, vos équipes ne subissent pas de rupture, et vous gardez la main sur le rythme comme sur la dépense.
L'ordre de traitement, lui, ne s'improvise pas. On corrige d'abord ce qui expose : les règles de confidentialité, les traitements de back-end ouverts. Puis ce qui coûte : les automatisations qui tournent pour rien, le plan surdimensionné, les recherches qui balaient toute la base. Puis ce qui ralentit vos équipes au quotidien. Les améliorations esthétiques viennent en dernier, même si ce sont celles qu'on voit le plus.
Un avertissement, parce que c'est une illusion fréquente : travailler à l'heure ne veut pas dire que le total sera plus faible. Cela veut dire qu'il sera étalé et pilotable. Nous y reviendrons à la fin de cet article, avec un cas concret où le total a largement dépassé le coût d'une reconstruction.
Si la dette est trop lourde, repartez au propre
Cela paraît radical. Ça ne l'est pas, pour la raison que nous avons développée plus haut : votre application actuelle est un prototype éprouvé, et c'est le meilleur document de cadrage qui existe.
Aux ateliers d'arts, c'est la décision que nous avons prise, et le calendrier a compté autant que la technique.
L'application avait été construite en 2022. Nous l'avons reprise en 2026. Entre-temps, elle était restée sur l'ancien système d'affichage de Bubble, celui d'avant le responsive : les écrans étaient positionnés en pixels fixes, sans adaptation à la taille de l'appareil. Concrètement, une école dont les élèves et les parents s'inscrivent majoritairement depuis un téléphone travaillait avec une application conçue pour un écran d'ordinateur, et rien d'autre. À cela s'ajoutaient des latences quotidiennes et une structure de données calquée sur une autre école.
Nous avons regardé ce qu'il faudrait pour réparer. Reprendre le responsive signifiait repositionner chaque élément de chaque page. Corriger la structure de données signifiait toucher à tout ce qui avait été construit dessus. Additionnées, ces deux reprises coûtaient davantage qu'une reconstruction, et laissaient l'application avec ses fondations d'origine.
La décision s'est prise en fonction d'une date : l'ouverture des inscriptions de l'année. Une école ne peut pas se permettre une plateforme instable au moment où arrive l'essentiel de son chiffre d'affaires annuel. Nous avons donc reconstruit, et livré avant cette date.
Ce que nous avons refait ne se limite pas à l'application. La plateforme d'inscription, le site public et le back-office des équipes ont été repris ensemble, parce que les trois racontent la même histoire et partagent les mêmes données.
Côté élève, l'inscription se fait de bout en bout : choix des cours, panier, réductions calculées automatiquement selon la composition du panier et les cursus retenus. C'est la règle métier qui, dans l'ancienne application, était appliquée à la main par le secrétariat, avec les erreurs que cela suppose. Les paiements suivent la réalité de l'école plutôt que la simplicité technique : virement, chèque, et paiement en plusieurs fois, chacun avec son suivi propre.
Côté équipes, le back-office donne les statistiques d'inscription et les exports sans passer par nous. C'est le point que les dirigeants sous-estiment le plus au moment du devis, et celui qu'ils citent en premier six mois plus tard.
Le résultat, chiffré : 70 % d'un mois d'inscriptions réalisées dès le premier jour d'ouverture.
Les autres cas où l'on repart de zéro
La dette technique n'est pas le seul motif de reconstruction. Trois autres reviennent régulièrement.
La limite technologique. Sur une plateforme de réservation d'espaces haut de gamme, nous avons buté sur des contraintes que la technologie d'origine ne permettait pas de dépasser. Pas « difficilement », pas « à condition d'y passer du temps » : pas du tout. Aucune quantité de travail n'aurait résolu le problème. C'est le cas le plus net, et paradoxalement le plus simple à décider : quand le plafond est structurel, la question n'est plus de savoir s'il faut changer de socle, mais quand.
Le besoin métier qui dépasse l'outil. Une entreprise industrielle voulait un vrai diagramme de Gantt pour piloter ses heures, ses projets et son planning. Pas une approximation visuelle qui donne l'illusion du pilotage. Une société immobilière avait besoin d'une fonction d'estimation nettement plus fine que ce que l'existant savait produire. Dans les deux cas, la fonctionnalité attendue n'était pas un confort : c'était le cœur du métier, la raison même d'avoir un outil. Une fonctionnalité centrale bridée par la technologie ne se contourne pas, elle se reconstruit.
L'accumulation d'anomalies. Une plateforme de formation cumulait latences et comportements erratiques au point que chaque correction en appelait deux autres. Il devenait moins coûteux de repenser entièrement les trois parcours (administration, encadrants, apprenants) que de continuer à colmater. Là encore, ce n'est pas un procès fait à qui l'a construite : c'est un constat arithmétique, posé avec les chiffres de maintenance sur la table.
Avant de quitter votre prestataire
Trois réflexes qui vous feront économiser des semaines, et qui se demandent tant que la relation est encore bonne.
Demandez une garantie de trois mois, valable tant que personne d'autre ne touche à l'application. C'est une demande normale, et la plupart des prestataires sérieux l'acceptent sans difficulté. Elle vous couvre pendant la période la plus risquée : celle où vous cherchez votre successeur et où plus personne ne surveille l'application au quotidien. La condition d'exclusivité est logique et protège les deux parties : dès qu'un tiers modifie l'application, plus personne ne peut garantir quoi que ce soit.
Exigez une documentation. Pas un manuel utilisateur : la logique. Comment les données sont organisées et pourquoi, quels choix ont été faits et dans quel contexte, où se trouvent les traitements automatiques, quelles sont les zones fragiles qu'il vaut mieux ne pas toucher sans prévenir. C'est ce document qui transforme un mois de rétro-ingénierie en une semaine de lecture. Rappelez-vous que son absence est le cas dans neuf reprises sur dix. Si vous devez ne demander qu'une seule chose, demandez celle-là.
Récupérez tous vos accès. Le compte de la plateforme et sa facturation à votre nom, le nom de domaine, les boîtes e-mail techniques, les comptes des services connectés (paiement, envoi d'e-mails, stockage de fichiers, outils tiers) et les clés d'accès associées. Cette liste paraît évidente. Elle est presque toujours incomplète, et chaque élément manquant se transforme en blocage au pire moment, quand la relation s'est refroidie et que plus personne ne répond aux messages.
L'intelligence artificielle ne va pas vous sauver sur l'existant
Il faut être clair, parce que beaucoup de monde raconte l'inverse en ce moment, et que la promesse est séduisante quand on a une application en difficulté.
Sur une application visuelle déjà construite, l'intelligence artificielle aide à repenser des écrans et à produire des maquettes. Elle ne reconstruit pas vos automatisations. Elle ne reprend pas vos traitements de back-end. Elle ne modifie pas des pages existantes. Sur ce terrain-là, aujourd'hui, elle ne fait pas gagner de temps.
La raison est simple : ces plateformes ne se pilotent pas par du texte. Ce qui fait votre application, ce sont des enchaînements construits à la souris, dans une interface, avec un état interne que rien n'expose sous une forme qu'une machine pourrait reprendre. Il n'y a pas de fichier à relire, pas d'historique à comprendre, pas de matière sur laquelle raisonner.
En revanche, l'intelligence artificielle change tout quand on repart au propre, à une condition qui n'est pas négociable : que la logique métier soit écrite avant.
Comment nous travaillons
C'est là que se joue la différence entre une application générée vite et une application qui tient trois ans.
Nous utilisons BMAD, la Breakthrough Method for Agile AI-Driven Development, un cadre de travail ouvert pour le développement assisté par intelligence artificielle. Son principe n'est pas de demander du code à une machine. Il est de répartir le travail entre des rôles spécialisés qui se passent le relais avec des documents écrits : l'analyste, le chef de produit, l'architecte, le développeur, le testeur. Chaque étape produit un livrable que la suivante reprend, exactement comme dans une équipe qui fonctionne bien.
Concrètement, pour chaque fonctionnalité, l'ordre ne se contourne jamais.
On écrit les spécifications. Ce que la fonctionnalité doit faire, dans le vocabulaire de votre métier.
On écrit les parcours utilisateurs, un par un. Qui fait quoi, dans quel ordre, avec quels droits, et ce qui se passe quand ça ne se passe pas comme prévu.
On écrit le plan de test. La liste de ce qui devra être vérifié pour considérer que la fonctionnalité est juste, y compris les cas tordus.
On écrit les tests. Avant le code. Ils échouent tous, et c'est normal : ils décrivent un comportement qui n'existe pas encore.
Puis seulement, on développe. La fonctionnalité est terminée quand les tests passent.
Cet ordre a une conséquence directe pour vous, et elle vaut d'être dite clairement : une correction ne peut plus en casser deux ailleurs sans que personne ne le voie. Les tests écrits pour les fonctionnalités précédentes tournent à chaque modification. C'est précisément le symptôme de la question 6, traité à la racine.
Ce qui produit un outil robuste, ce n'est donc pas l'outil de génération. C'est la rigueur de ce qu'on lui donne à traiter, la hiérarchie de l'information qu'on lui fournit, et les documents de référence auxquels on le ramène en permanence. Une machine qui code très vite sur des règles métier floues produit très vite une application floue.
Et l'intelligence artificielle dans votre produit
Dernier point, souvent oublié au moment du devis : l'intelligence artificielle embarquée dans votre application a un coût récurrent, à chaque usage. Ce n'est pas une fonctionnalité qu'on paie une fois, c'est une consommation qui suit votre croissance.
On l'intègre donc quand elle sert le métier, et on écrit ses règles comme on écrit les autres. Une intelligence artificielle sans règle métier explicite prend des décisions que personne n'a validées. Jamais parce qu'elle fait moderne.
Le vrai sujet : votre autonomie
C'est la phrase qui revient chez tous nos clients, à un moment ou à un autre. « Je veux pouvoir changer un texte sans appeler mon développeur. »
Elle paraît anodine. Elle ne l'est pas : c'est la question de savoir qui contrôle votre outil de travail.
Sur une plateforme visuelle, rendre tout modifiable suppose de construire un back-office considérable : un écran d'administration pour chaque chose que vous voudrez changer un jour. Cet écran doit lui-même être conçu, testé et maintenu, et il alourdit l'application entière. Résultat, le calcul du développeur est imparable : il est plus rapide qu'il fasse la modification lui-même.
Il a raison sur l'instant. Et vous perdez sur la durée.
Parce que chaque changement de tarif, chaque correction de formulation, chaque nouvelle condition générale devient un ticket, un délai, une facture. Et parce que vous dépendez d'une disponibilité qui n'est pas la vôtre. Au moment précis où vous en avez besoin, votre développeur est sur un autre projet.
C'est précisément là qu'une application métier sur mesure change la donne. L'outil vous appartient. Vos équipes modifient ce qui doit l'être : les textes, les tarifs, les conditions, les paramètres, les utilisateurs et leurs droits. Et vous n'appelez votre constructeur que pour ce qui en vaut vraiment la peine.
C'est le sens du dernier temps de notre méthode : vous devez rester propriétaire de votre système. Pas de boîte noire, pas de « il faut repasser par nous pour changer un bouton ».
L'autonomie n'est pas un confort d'usage. C'est ce qui fait qu'une entreprise continue de tourner quand son dirigeant s'absente trois semaines.
Ce qui se passe pendant un cadrage
C'est la phase que personne ne veut payer, et c'est celle qui décide de tout le reste. Elle mérite qu'on explique ce qu'il s'y passe réellement, parce que « cadrage » ne veut rien dire pour qui ne l'a jamais vécu.
Un cadrage ne consiste pas à lister des fonctionnalités. Il consiste à écrire vos règles métier : votre logique, vos objectifs, vos exceptions.
Quelques exemples de vraies questions de cadrage, prises dans de vrais projets.
Que se passe-t-il quand un client annule après la date limite ? Rembourse-t-on, avoir-t-on, facture-t-on des frais, et qui décide ?
Comment se calcule une remise quand deux conditions s'appliquent en même temps ? Elles se cumulent, ou la plus favorable l'emporte ?
Qui a le droit de valider quoi, et que se passe-t-il quand cette personne est absente ? Le circuit se bloque, ou quelqu'un d'autre reprend la main ?
Que fait-on d'une donnée incomplète : on refuse l'enregistrement, ou on l'accepte avec une alerte ?
Ces règles ne figurent dans aucun cahier des charges. Elles vivent dans la tête de deux ou trois personnes, elles se transmettent oralement, et elles s'appliquent au cas par cas, parfois différemment selon qui traite le dossier. C'est très exactement ce qui rend votre entreprise dépendante de ces personnes.
Le cadrage les sort de ces têtes et les met sur le papier. C'est un exercice inconfortable, parce qu'il oblige à trancher des situations qu'on avait toujours réglées à l'instinct. C'est aussi ce qui fait qu'un outil sur mesure finit par ressembler à votre métier au lieu de ressembler à un logiciel.
Et c'est là que le prototype dont nous parlions prend toute sa valeur : quand une application existe déjà, la moitié de ces questions a déjà trouvé sa réponse dans l'usage.
Ce que ça coûte, et en combien de temps
Une plateforme complète, chez nous, se livre en huit semaines.
La moitié de ce temps, trois à quatre semaines, est du cadrage. C'est ce qui surprend le plus, et c'est ce qui fait la différence. Le développement vient après, et il va vite précisément parce que tout a été tranché avant. L'ordre inverse produit des allers-retours sans fin : on développe, on montre, le client découvre en voyant l'écran que ce n'était pas ça, on refait. C'est de là que viennent les projets à rallonge, et jamais d'un manque de compétence technique.
Le budget se situe entre 10 000 et 18 000 euros pour une plateforme complète.
Pourquoi un écart aussi large
C'est une question légitime, et l'écart n'est pas de la prudence commerciale. Il tient à quatre facteurs, qui font tous varier la même chose : le nombre de cas à concevoir, à construire et à tester.
Le nombre d'interfaces. Une application qui sert un seul public demande un parcours. Une application qui sert trois publics, par exemple une administration, des encadrants et des apprenants, en demande trois, pensés séparément, avec leurs écrans, leurs droits et leurs règles propres. Ce n'est pas trois fois le même travail décliné : chaque public a ses attentes et son vocabulaire.
Les rôles cumulés. C'est le facteur le plus sous-estimé, et celui qui fait le plus grimper un devis. Dès qu'un même utilisateur peut porter plusieurs casquettes (un encadrant qui est aussi apprenant sur un autre cursus, un chef d'équipe qui est aussi opérateur), il faut définir ce qu'il voit dans chaque situation, ce qu'il a le droit de faire, et ce qui se passe quand ses deux rôles entrent en conflit. Le nombre de cas ne s'additionne pas : il se multiplie.
La densité des règles métier. Une inscription simple, c'est un formulaire. Une inscription avec des réductions qui dépendent du panier, des cursus, de l'ancienneté et du mode de paiement, c'est un moteur de calcul. Le nombre d'écrans est le même. Le travail n'a rien à voir.
Les connexions avec l'extérieur. Paiement, facturation, comptabilité, envoi d'e-mails, signature électronique. Chaque service branché apporte ses propres cas d'erreur, et il faut décider ce qui se passe quand il ne répond pas. Ce qui arrive toujours un jour.
Un devis sérieux nomme ces quatre facteurs pour votre projet. S'il ne le fait pas, demandez pourquoi.
Enfin, ces délais supposent que vous soyez disponible. Un cadrage s'arrête quand les réponses s'arrêtent, et c'est le seul facteur de retard que nous ne maîtrisons pas.
Si vous voulez le détail de ce qui fait varier un budget, nous l'avons écrit ici : combien coûte un logiciel sur mesure. Si le terme lui-même reste flou, c'est quoi un logiciel métier sur mesure pose les bases. Et pour l'arbitrage entre acheter une solution du marché et construire la vôtre, voyez progiciel ou logiciel.
Les questions à poser à votre prochain constructeur
Cinq questions. Les réponses vous renseigneront plus qu'un portfolio.
« Combien de temps vous faut-il avant de pouvoir me chiffrer la reprise ? » Si la réponse est « on peut vous dire ça tout de suite », passez votre chemin. Vous savez maintenant pourquoi.
« Que se passe-t-il si vous découvrez que tout est à refaire ? » La bonne réponse décrit un point d'étape, un livrable d'audit et une décision partagée. Pas une promesse rassurante.
« Qu'est-ce que vous me livrez en plus de l'application ? » Documentation, accès, transfert de propriété. Si ce n'est pas écrit dans le devis, ce ne sera pas fait.
« Que puis-je modifier moi-même, sans vous ? » La réponse dessine très exactement votre dépendance des trois prochaines années.
« À qui appartient l'application à la fin ? » Elle doit vous appartenir. Sans réserve, sans clause, sans condition de maintenance.
Le mauvais calcul
Le réflexe le plus coûteux, en reprise, c'est de vouloir sauver l'existant à tout prix parce qu'il a déjà été payé.
Nous accompagnons en ce moment une entreprise qui a fait ce choix. L'application est restée sur sa technologie d'origine, par prudence et parce qu'elle représentait déjà un investissement lourd. Nous sommes le troisième prestataire à intervenir dessus : deux autres sont passés avant nous. Le travail se fait à l'heure, poste par poste, sans jamais toucher aux fondations.
Le total de nos seules heures atteint aujourd'hui le prix d'un développement neuf. Nos heures uniquement. Nous ne connaissons pas ce qu'ont facturé les deux prestataires précédents, et le cumul réel dépasse donc largement ce chiffre.
Personne n'a mal travaillé. Chaque intervention, prise isolément, était justifiée et correctement réalisée. Mais chacune s'est ajoutée à une base qui n'a jamais été reprise, et le total, avec le recul, est considérable. Rapporté à ce que coûte aujourd'hui une reconstruction, l'écart n'est plus discutable.
C'est le point que nous voulons faire passer, et il est contre-intuitif : rester sur une technologie parce qu'on y a déjà investi peut coûter bien plus cher que d'en changer. Ce n'est pas la prudence qui a coûté, c'est le refus de refaire le calcul.
L'argent déjà dépensé est dépensé. Il ne reviendra pas, quelle que soit la décision que vous prenez maintenant. Le faire entrer dans l'arbitrage, c'est laisser une dépense passée décider d'une dépense future. C'est le raisonnement le plus onéreux qui soit.
La seule question qui compte porte sur les douze mois à venir. Combien va vous coûter cette application telle qu'elle est : en heures de correction, en lenteur pour vos équipes, en erreurs que personne ne voit passer, en évolutions que vous ne demandez plus.
Notre objectif est de ce côté-là de la balance. Une plateforme doit vous coûter moins que ce qu'elle vous rapporte. Du temps rendu à vos équipes, des erreurs qui disparaissent, des décisions prises sur des chiffres justes, une entreprise qui tourne quand vous n'êtes pas là. C'est ce que nous appelons une application rentable, et c'est la seule mesure qui vaille. Pas le nombre d'écrans livrés.
Faites ce calcul avant de demander un devis. Il décide tout seul.