Sommaire
Avant de mettre un prototype en production, vérifiez d’abord les droits d’accès côté serveur, les clés secrètes, les sauvegardes testées, la séparation test-production et la propriété des comptes. Un audit (589 à 1 990€HT) dit ce qui manque ; une remise à niveau complète se chiffre comme une application métier, dès 6 000€HT.
Un collaborateur a construit un outil avec Lovable, Bolt, Bubble ou un tableur amélioré. L’équipe l’adopte, l’usage grandit et un jour quelqu’un propose d’y mettre les vrais clients, les vrais prix, les vraies données RH. C’est le moment où un prototype devient un outil de production et où les risques changent de nature. Voici les vérifications à faire avant ce passage, l’ordre dans lequel je les traite et ce que cela coûte.
Prototype et production : ce qui change vraiment
Un prototype répond à une question : « l’idée fonctionne-t-elle ? ». Un outil de production doit répondre à d’autres : que se passe-t-il si un utilisateur se trompe, si quelqu’un essaie de voir ce qu’il ne devrait pas, si le serveur tombe, si la personne qui l’a construit part ?
| Dimension | Prototype | Outil de production |
|---|---|---|
| Données | Fictives ou copiées | Réelles, personnelles, financières |
| Utilisateurs | Le créateur et quelques testeurs | Toute une équipe, parfois des clients |
| Sécurité | Contrôles à l’écran | Contrôles côté serveur, droits par rôle |
| Panne | Gênante | Bloque l’activité |
| Sauvegardes | Absentes ou jamais testées | Automatiques, restauration testée |
| Évolutions | Directement sur l’outil | Testées dans un environnement séparé |
| Dépendance | Une personne | Documentation et accès partagés |
Les dix vérifications avant de passer en production
C’est la liste que je reprends dans chaque audit de prototype. Elle complète la checklist du guide créer son application soi-même avec l’IA.
- Droits d’accès vérifiés côté serveur : chaque utilisateur ne voit et ne modifie que ce qu’il doit, même en appelant l’API directement.
- Aucune clé secrète dans le code envoyé au navigateur ni dans l’historique du dépôt.
- Comptes nominatifs, pas de compte partagé et une double authentification pour les administrateurs.
- Sauvegardes automatiques de la base et des fichiers, avec une restauration déjà testée.
- Deux environnements : un pour tester, un pour travailler.
- Code dans un dépôt Git appartenant à l’entreprise.
- Accès techniques rattachés à l’entreprise : base, hébergement, domaine, services tiers, avec deux administrateurs au moins.
- Données personnelles cadrées : registre des traitements, durée de conservation, hébergement connu.
- Journal des actions sensibles : qui a modifié un prix, supprimé une fiche, exporté des données.
- Une personne capable de reprendre : documentation minimale, code lisible.
En dessous de huit points sur dix, je déconseille de mettre des données réelles dans l’outil.
Dans quel ordre traiter les écarts
Tout ne se fait pas en même temps. Ma priorité suit le niveau de risque :
- D’abord ce qui peut faire fuir ou perdre des données : droits d’accès, clés exposées, sauvegardes. Voir la page sauvegardes et plan de reprise.
- Ensuite ce qui protège l’entreprise de la dépendance : propriété des comptes, dépôt de code, documentation.
- Puis ce qui sécurise les évolutions : environnement de test, tests des parcours critiques.
- Enfin le confort : performances, finitions, nouvelles fonctions.
Si l’audit montre que la base est trop fragile pour être corrigée, la reconstruction devient l’option la plus économique. Le prototype garde alors toute sa valeur : il sert de cahier des charges.
Ce que coûte le passage en production
| Étape | Prix | Délai |
|---|---|---|
| Audit express du prototype | 589€HT | Quelques jours |
| Audit complet (sécurité, données, code, performances) | 1 990€HT | 5 à 7 jours |
| Remise à niveau ciblée | Sur devis après audit | Selon le plan d’action |
| Reconstruction en application métier | 6 000 à 20 000€HT, coefficient 0,85 dans l’estimateur avec un prototype | 1 à 3 mois |
| Accompagnement si vous gardez la main | Coaching à 150€HT de l’heure | À votre rythme |
Pour une estimation qui tient compte de votre prototype, utilisez l’estimateur. Après la mise en production, prévoyez l’hébergement (quelques dizaines à quelques centaines d’euros par an) et la maintenance ; trois mois de support sont inclus dans mes projets.
Quand ce n’est pas nécessaire
Je le dis franchement : un outil utilisé par deux personnes, sur des données non sensibles, que l’on pourrait reconstruire en une journée s’il disparaissait, n’a pas besoin de cette démarche complète. Une sauvegarde régulière et des comptes rattachés à l’entreprise suffisent. De même, si un logiciel du marché fait déjà 90 % de ce que fait votre prototype, il peut être plus sage de l’adopter et de garder le prototype pour ce qui manque.
Par où commencer
- Faites l’inventaire des accès et vérifiez qu’ils appartiennent à l’entreprise.
- Sauvegardez tout de suite le code, la base et les fichiers, avant toute nouvelle modification.
- Passez la checklist ci-dessus honnêtement, avec la personne qui a construit l’outil.
- Demandez un audit dans le cadre de mon offre projet commencé avec l’IA : vous obtenez un état des lieux et un plan d’action chiffré, puis vous décidez entre remise à niveau, reconstruction ou accompagnement.
Questions fréquentes
Mon prototype fonctionne, pourquoi ne pas le mettre en production tel quel ?
Parce qu’un prototype est conçu pour montrer que l’idée tient, pas pour résister à des erreurs, à des utilisateurs curieux ou à une panne. Tant qu’il manipule des données fictives, ce n’est pas grave. Dès que les données sont réelles, une faille ou une perte devient un vrai problème pour l’entreprise.
Combien de temps prend le passage en production ?
L’audit prend de quelques jours à une semaine. Ensuite, une remise à niveau ciblée peut tenir en quelques semaines si la base est saine ; une reconstruction suit le calendrier d’une application métier, de 1 à 3 mois.
Faut-il un environnement de test séparé ?
Oui. Tester une correction directement sur l’outil que l’équipe utilise, avec les vraies données, est la cause la plus fréquente d’incidents évitables. Un environnement de test avec des données d’essai permet de valider chaque évolution avant de la publier.
Qui doit être propriétaire des comptes techniques ?
L’entreprise, jamais une personne seule. Dépôt de code, base de données, hébergement, nom de domaine, comptes des services tiers : chacun doit être rattaché à une adresse de l’entreprise, avec au moins deux administrateurs.
Le RGPD s’applique-t-il à un outil interne ?
Oui, dès qu’il contient des données personnelles, y compris celles des salariés ou des contacts clients. Il faut notamment l’inscrire au registre des traitements et limiter les accès. La page sur le RGPD et les applications métier détaille les obligations, sans remplacer l’avis d’un juriste.