Un nouveau type de mission arrive chez les freelances. Des fondateurs non techniques, une app construite entièrement par IA, de vrais utilisateurs en approche. Et une question : « vous pouvez finir le travail ? »
TL;DR : je viens de vivre cette mission. Ma règle : jamais de devis au téléphone. Une journée d'audit de cadrage, non facturée mais time-boxée, avant tout chiffrage. Les apps générées partagent des patterns de failles documentés, et un budget serré se traite par un devis en lots, sécurité d'abord. Les findings précis restent chez le client. La méthode, elle, se partage.
Cet article est pour les freelances qui reçoivent ces demandes, et pour les fondateurs qui s'apprêtent à en envoyer une.
Le rendez-vous type de 2026
La scène se généralise. Deux fondateurs, aucun dev dans l'équipe. Une app construite sur un app-builder IA, du genre Lovable, jusqu'à épuisement des crédits.
Puis un ami développeur jette un œil et donne l'alerte : des données personnelles exposées. Les fondateurs gèlent les changements, et cherchent un professionnel.
Ajoute les contraintes classiques. Un budget de quelques milliers d'euros. Une deadline de mise sur les stores en semaines, pas en mois. Plusieurs freelances en concurrence.
Ce rendez-vous, je viens de le vivre. Il va devenir banal.
Pourquoi je ne chiffre jamais au téléphone
Sans lecture du code, une estimation de reprise oscille d'un facteur dix. La mienne a fondu après lecture : le code était meilleur que craint.
C'est le piège dans les deux sens. Chiffrer trop haut fait fuir un client viable. Chiffrer trop bas t'enferme dans un forfait perdant.
Ma règle : un audit de cadrage d'une journée, avant tout devis. Non facturé, parce que c'est de l'avant-vente face à des concurrents. Time-boxé, parce que le non-facturé sans limite est une pente.
Le livrable est double : un rapport lisible par des non-techniciens, et un devis découpé que le rapport justifie ligne par ligne.
Ce que je regarde en une journée
Une journée ne permet pas l'exhaustivité. Elle permet de trouver les patterns qui décident du devis. Mon ordre de lecture ne change pas.
D'abord, le modèle d'accès aux données. Qui parle à la base, avec quels droits ? C'est la question qui domine toutes les autres.
Ensuite, les endpoints publics : ce qu'ils renvoient, champ par champ. Puis tout ce qui touche l'argent : types, validations, webhooks des prestataires de paiement.
Ensuite, l'historique git et les migrations. L'état réel d'une base générée par IA diverge souvent de ce que les fichiers racontent.
Enfin, les secrets et leur hygiène. Et les points positifs, notés avec le même sérieux : ils crédibilisent le reste du rapport.
Les patterns que tu vas trouver
Les failles des apps générées ne sont pas des surprises artisanales. Elles sont documentées et se répètent.
La référence publique : CVE-2025-48757. Un chercheur a scanné des apps construites avec Lovable. Environ 10 % avaient une Row Level Security absente ou cassée. La RLS est le mécanisme de Postgres qui filtre les lignes par utilisateur.
Le pattern le plus sournois est plus subtil : des policies RLS correctes, mais un serveur qui interroge la base avec la clé d'admin. La barrière existe, tout passe par-dessus. Une policy contournée ne protège rien.
Les suivants reviennent presque à chaque fois. Des endpoints publics qui renvoient tous les champs au lieu du strict nécessaire. Aucun rate limiting, donc une énumération triviale. L'argent manipulé en nombres flottants, sans contrainte en base.
Mon préféré : des utilitaires de sécurité générés par l'IA, propres, testés, et jamais branchés. L'outil écrit la fonction de masquage, puis ne l'appelle pas.
Dans l'app que je viens d'auditer, plusieurs de ces patterns étaient au rendez-vous. Je ne dirai pas lesquels : les findings précis appartiennent au client. Les patterns, eux, appartiennent à tout le monde.
Le devis en lots, ou rien
Le budget annoncé couvre rarement le périmètre rêvé. L'écart se traite par le découpage, pas par le marchandage.
Lot 1 : la sécurité des données. Fermer les fuites, contrôler les accès, poser les contraintes critiques. Ce lot rentre dans l'enveloppe, et il couvre ce qui peut faire mal aux utilisateurs.
Lot 2 : la fiabilité des flux d'argent. Lot 3 : la préparation à la mise en production. Chacun a son prix, le client choisit en connaissance de cause.
Et une ligne rouge : jamais de forfait global « jusqu'à la validation des stores ». Les allers-retours de review ne dépendent pas de moi. Promettre un délai qu'un tiers contrôle, c'est fabriquer un litige.
Ce que je dis aux fondateurs
Trois messages, sans détour.
Un : votre app générée n'est pas une poubelle. La structure était lisible, des tests existaient, certains réflexes étaient bons. Le rapport le dit, parce que c'est vrai et parce que ça crédibilise les alertes.
Deux : la sécurité passe avant les features, parce que de vraies données et de vrais paiements circulent. Le lot 1 n'est pas négociable dans son contenu, seulement dans son calendrier.
Trois : les obligations réglementaires ne disparaissent pas en changeant de prestataire. Ce qui est obligatoire chez l'un le sera chez l'autre.
La checklist de l'audit de cadrage
Une journée, dans cet ordre. Le devis sort presque tout seul.
- Time-boxe l'audit : une journée, livrable écrit, pas une heure de plus
- Commence par le modèle d'accès : qui parle à la base, avec quels droits
- Cherche les chemins qui contournent la RLS avec une clé d'admin
- Liste les endpoints publics et chaque champ qu'ils renvoient
- Suis l'argent : types, contraintes en base, webhooks et leurs vérifications
- Compare l'état réel de la base à ce que les migrations racontent
- Vérifie les secrets dans le git, sur tout l'historique
- Note les points positifs, et découpe le devis en lots, sécurité d'abord
Ce qu'il faut retenir
Les reprises d'apps codées à l'IA vont remplir les boîtes mail des freelances. La compétence différenciante n'est pas de mépriser ce code. C'est de savoir l'auditer vite, et de chiffrer honnêtement.
Une journée d'audit, des patterns connus, un devis en lots. Le reste est de l'exécution.
Tu as une app générée à sécuriser avant son lancement, ou une reprise à cadrer ? Parlons-en.