Votre application marche en démo.
Nous la rendons solide.
Sans tout refaire.
Nous relisons le code, fermons ce qui est ouvert, installons l'application sur un hébergement à vous et restons joignables le jour où elle casse.
Vous avez fait construire une application en quelques jours, ou vous l'avez construite vous-même, avec Lovable, Bolt, Cursor ou ChatGPT. Elle fonctionne, des collègues ou des clients s'en servent déjà. Et personne chez vous ne peut dire ce qu'il y a dedans : où partent les données, qui peut les lire, ce qui se passe le jour où cent personnes se connectent en même temps.
Nous reprenons l'application telle qu'elle est, nous la consolidons, et nous vous la laissons. Le code reste dans votre dépôt, et l'outil qui l'a écrit reste utilisable si vous voulez continuer avec.
Réponse sous 24 à 48 h ouvrées, par la personne qui fera la relecture.
Vous vous reconnaissez dans au moins deux de ces phrases.
Ce sont les phrases que nous entendons au premier appel, dites avec les mots des dirigeants qui nous appellent.
Garder, reprendre ou refaire votre application : comment trancher.
Une application construite vite n'a pas toujours besoin de nous. Voici comment nous tranchons au premier appel, et vous pouvez faire le même tri sans nous.
Gardez-la telle quelle tant qu'elle reste un prototype.
Une démo pour convaincre un client, un outil interne utilisé par trois personnes sans données sensibles : elle fait son travail. Une relecture coûterait plus cher que ce qu'elle protège. Notez seulement ce qu'il faudra faire le jour où elle sortira de ce cadre.
Faites-la reprendre dès que de vraies données y passent.
Des clients qui créent un compte, des paiements, des données personnelles, des documents internes. À partir de là, une fuite ou une perte de données a un coût, devant vos clients comme devant la loi. La reprise garde ce qui marche et ferme ce qui est ouvert.
Faites-la refaire quand le code ne se lit plus.
Cela arrive : des blocs entiers écrits trois fois, chaque correction qui en casse deux autres, une structure que l'outil a changée en cours de route. Corriger coûte alors plus cher que reconstruire à partir de ce que l'application a appris à vos utilisateurs. Nous vous le disons à la fin de la relecture, jamais avant, et vous décidez. Notre guide sur la refonte d'un logiciel détaille ce choix.
Et si l'outil vous fait gagner du temps, continuez avec.
Lovable, Bolt ou Cursor restent de bons outils pour avancer vite. Après la reprise, vous pouvez continuer à vous en servir, sur un dépôt propre, avec des tests qui préviennent dès qu'une modification casse un parcours qui compte.
Comment se passe la reprise d'une application codée vite.
Trois temps. La relecture aboutit à un compte rendu chiffré. La consolidation commence par ce qui protège. La suite se décide avec vous.
Relecture du code : une à deux semaines.
Nous lisons tout le code sans rien modifier : où vivent les données, qui peut y accéder, quelles clés traînent dans les fichiers, ce qui casse quand dix personnes se connectent en même temps, ce que l'outil a écrit deux fois. Vous recevez un compte rendu lisible sans être développeur, avec ce qui tient, ce qui ne tient pas et ce que coûte chaque correction. C'est la démarche que nous appliquons à la dette technique d'un logiciel plus ancien, adaptée à un code écrit en quelques jours.
Consolidation : ce qui protège passe en premier.
Nous commençons par ce qui peut vous coûter cher : les mots de passe et les clés sortis du code, les droits d'accès vérifiés page par page, les données sauvegardées, les formulaires et les envois de fichiers contrôlés. Viennent ensuite des tests automatiques sur les parcours qui comptent (l'inscription, le paiement, ce que vos clients font tous les jours), puis l'installation sur un hébergement dont vous détenez les accès.
La suite : vous reprenez la main, ou nous restons.
Le code arrive dans votre dépôt avec une documentation de quelques pages. Un développeur de votre choix peut continuer, vous pouvez continuer avec l'outil qui a écrit le code, ou nous restons en suivi mensuel pour les corrections et les évolutions.
Ce que vous obtenez.
Quatre choses concrètes, toutes chez vous le jour où la mission se termine.
Un compte rendu que vous pouvez lire.
Ce qui tient, ce qui est ouvert, ce qui coûte à garder, classé par risque. Écrit pour un dirigeant, avec les termes techniques expliqués quand on ne peut pas les éviter. Vous pouvez le confier à un autre prestataire si vous le souhaitez.
Une application qui ne laisse plus rien d'ouvert.
Les clés hors du code, les droits vérifiés écran par écran, des formulaires qui refusent ce qu'ils n'attendent pas. Une personne qui n'a pas de compte ne voit que ce qui est public.
Un hébergement et des sauvegardes à votre nom.
L'application tourne sur un serveur dont vous détenez les accès, sauvegardée chaque jour. Nous restaurons une sauvegarde au moins une fois devant vous avant de partir, pour que vous sachiez qu'elle sert à quelque chose.
Le code dans votre dépôt, avec ses tests.
Les parcours qui comptent sont couverts par des tests automatiques. Le jour où quelqu'un modifie le code, à la main ou avec un outil, vous savez tout de suite si quelque chose a cassé.
Ce que nous nous engageons à ne pas vous faire subir.
La liste vient de ce qu'ont vécu des entreprises passées par un premier prestataire avant de nous appeler.
Du code que plus personne ne maîtrisait, repris et remis d'aplomb.
Deux situations proches de la vôtre. Dans la première, il a fallu reconstruire. Dans la seconde, l'équipe garde ses outils et apprend à s'en servir sans casse.
GAG, association des arbitres genevois.
Les inscriptions aux formations vivaient dans un site dont le fonctionnement n'était plus documenté, et les pièces d'identité des candidats y traînaient sans contrôle d'accès clair. Il a fallu reconstruire, et nous avons d'abord récupéré tout l'historique, 557 inscrits et 18 sessions, puis placé les 1 355 pièces d'identité derrière un accès réservé au comité, avec une revue de sécurité des formulaires, des envois de fichiers et des accès administrateur. Lire le cas
Hairdex, téléconsultation capillaire.
Neuf applications, trois développeurs, et des assistants qui écrivent déjà du code dans chaque dépôt, chacun avec sa méthode, sans aucun test automatisé. Sur une plateforme où circulent des ordonnances, nous formons l'équipe sur ses propres dépôts : les tests d'abord, sur les parcours qui touchent au patient, puis une relecture de code branchée sur chaque modification proposée. La mission est en cours, et nous ne publions pas de chiffre avant le bilan avec l'équipe. Lire le cas
Votre situation est différente ? Faites d'abord passer votre site à notre analyseur : il relève en quelques minutes ce qui se voit de l'extérieur. Si votre application est un logiciel métier plus ancien, notre guide sur le logiciel sur mesure vous aidera à choisir entre garder, adapter et faire construire.
Les Q/R.
Combien coûte la reprise d'une application codée avec l'IA ?
La relecture se facture comme un cadrage : 3 900 € HT pour une application, 5 000 € HT quand plusieurs applications passent en revue. Le prix est fixé et signé avant de commencer. La consolidation se chiffre ensuite à partir du compte rendu, poste par poste, et vous choisissez ce que vous faites faire.
Combien de temps prend la relecture du code ?
Une à deux semaines selon la taille du code. Une heure avec vous au début pour comprendre à quoi sert l'application et qui s'en sert, une heure à la fin pour parcourir le compte rendu ensemble.
Faut-il tout refaire ?
La relecture répond à cette question avec des éléments : ce qui tient, ce qui ne tient pas, et ce que coûte chaque correction comparé à une reconstruction. Si refaire revient moins cher que corriger, nous vous le disons avant de facturer quoi que ce soit d'autre.
À qui appartient le code écrit par Lovable, Bolt ou Cursor ?
Le code produit vous revient selon les conditions de l'outil utilisé, que nous lisons avec vous pendant la relecture. Après la reprise, il vit dans votre dépôt, et un autre développeur peut le reprendre sans nous.
Peut-on continuer à utiliser l'outil après la reprise ?
Oui. Nous branchons l'application sur un dépôt propre, avec des tests automatiques sur les parcours qui comptent. Vous pouvez continuer à faire écrire du code par l'outil : les tests préviennent dès qu'une modification casse quelque chose.
Comment savoir si les données de nos clients sont protégées ?
Sans lire le code, personne ne peut le dire, et c'est la première chose que la relecture regarde : où les données sont stockées, qui peut les lire, si elles sont sauvegardées. Deux vérifications sont à votre portée dès aujourd'hui : ouvrir une page réservée sans être connecté, et demander à celui qui a construit l'application où se trouve la dernière sauvegarde.
Et après la reprise, qui s'occupe de l'application ?
Vous choisissez. Un développeur de votre équipe reprend la main avec la documentation, ou nous restons en suivi mensuel pour les corrections et les évolutions, avec arrêt libre le mois suivant.
Si vous avez lu jusqu'ici, prenons 30 minutes.
30 minutes en visio. Vous nous montrez l'application et la façon dont on s'en sert chez vous. À la fin de l'appel, vous saurez si une relecture vaut le coup, ou si elle peut rester comme elle est.
Réponse sous 24 à 48 h ouvrées, par la personne qui fera la relecture.
L'équipe fondatrice
Votre interlocuteur Techmind · vous parlerez directement à l'un d'entre nous, sans intermédiaire