Au chapitre 4, « Construire avec l'IA », vous avez obtenu une chose qui fonctionne. C'est ici que commence la phase 4, « publier » — vérifier avec des tests que rien ne casse, boucher les trous de sécurité, puis rendre le produit public. Ne vous contentez pas de « ça marche » : amenez-le jusqu'à un état où d'autres peuvent y toucher en confiance. Ça semble ardu, mais là encore, l'IA est votre partenaire.
« Même inachevé, livrer d'abord à une personne, en sécurité »
« Avoir créé » et « pouvoir publier » sont deux choses
Ce qui marche sur votre ordinateur et ce que d'autres peuvent manipuler sans risque sont deux choses différentes. Vous connaissez « la bonne façon d'utiliser », donc ça fonctionne comme prévu. Mais une fois public, arrivent des entrées, des manipulations et des intentions malveillantes que vous n'aviez pas prévues. Ceux qui envoient un champ vide, ceux qui collent une masse de symboles, ceux qui cherchent à espionner les données d'autrui…
Pas besoin pour autant de se crisper. Ce qu'il faut faire en premier en dev indépendant, ce sont 3 points tout à fait basiques. « Est-ce que ça casse », « les secrets ne fuient-ils pas », « les données d'autrui sont-elles protégées ». Ce chapitre est là pour franchir ce minimum avec l'IA et publier la tête haute.
On n'y touche que dans les règles. Une erreur ? On la corrige soi-même. Un secret affiché à l'écran ? Peu importe.
Des entrées imprévues arrivent. Un écran d'erreur fait fuiter des infos internes. Une clé publiée par mégarde peut entraîner une facture salée ou une fuite de données.
Confier tests et relecture à l'IA
« Seul, je n'ai pas de mentor pour relire mon code » — ce rôle-là, confiez-le justement à l'IA. Le code que vous avez écrit (ou fait écrire par l'IA), refaites-le inspecter par l'IA sous un autre angle. Celui qui écrit (humain comme IA) remarque mal ses propres erreurs. D'où l'intérêt de nommer un « auditeur ».
La méthode est simple. Collez le code et demandez juste ceci : « Relève les bugs, les entrées dangereuses et les tests manquants de ce code. » Une liste des trous que vous n'aviez pas vus vous revient. Ensuite, corrigez un par un, en commençant par les plus prioritaires. Ne cherchez pas à tout corriger d'un coup : corriger un point, vérifier, corriger un autre — voilà l'astuce.
Quand vous demandez un audit à l'IA, expliciter les angles suivants améliore la précision.
« Dans quels cas ça plante ? », « et si on passe un champ vide ou zéro ? » Faites chercher à l'IA les conditions de casse.
Chaînes malveillantes, données énormes, fichiers invalides. Demandez « comment un attaquant s'y prendrait-il ? »
« Quels cas devraient être vérifiés mais ne le sont pas ? » Faites recenser valeurs limites et exceptions.
« Une clé API ou un mot de passe est-il écrit en dur dans le code ? » Coupez la fuite dans l'œuf.
💡 Un test, c'est « un mécanisme qui vérifie automatiquement ». Sur la route pratique, faites même écrire les tests par l'IA. Demandez « écris les tests de cette fonction : cas normaux, et cas de champ vide ou de valeur anormale », et vous pourrez revérifier d'un seul clic que rien n'a cassé après une correction. Sur la route débutant, « essayer exprès des manips bizarres à la main » est déjà un pas suffisant.
Les 3 minimums de sécurité
La sécurité est un domaine profond, mais à la publication d'un dev indépendant, retenez seulement les 3 points à sécuriser absolument d'abord. Manquer ces 3-là peut vous faire perdre d'un coup argent, confiance et données d'autrui. À l'inverse, si vous les tenez, c'est suffisant pour une première publication.
Clés API, mots de passe, jetons : ne pas les écrire en dur dans le code. Sortez-les vers un fichier de variables d'environnement comme .env, et excluez ce fichier de la publication (ajoutez-le à .gitignore).
S'il y a une fonction de connexion, faites en sorte qu'un utilisateur A ne puisse voir que ses propres données. Faites vérifier par l'IA et insérez toujours ce contrôle de propriété : « ces données appartiennent-elles vraiment à cette personne ? »
Les clés de services externes et les droits sur la base : juste ce qu'il faut. Ne distribuez pas de clé « qui peut tout faire ». Émettez des clés à usage limité — jetables, en lecture seule — selon l'usage.
🚨 Ne publiez jamais une clé secrète. C'est l'accident le plus fréquent, et le plus coûteux, du dev indépendant. Une clé API laissée en dur dans le code et publiée sur GitHub par exemple est repérée et exploitée automatiquement en quelques minutes à quelques heures. Avec une API payante, une facture de plusieurs milliers d'euros au moment où l'on s'en aperçoit, ça arrive réellement. Avant de publier, faites toujours vérifier par l'IA « reste-t-il une clé dans le code ? ». Et une clé publiée ne serait-ce qu'une fois, la supprimer ne suffit pas : révoquez-la et régénérez-en impérativement une nouvelle.
Si ça vous paraît difficile, demandez simplement à l'IA : « Avant de publier ce code, dis-moi, pour un débutant, ce qu'il faut faire côté sécurité. » Une checklist concrète, adaptée à votre code, vous revient.
Faire tourner l'automatisation en sécurité (route pratique)
Ceci concerne surtout la 🔧 route pratique. Confier automatiquement à un agent IA comme Claude Code les opérations sur fichiers et l'exécution de commandes accélère énormément le développement. Mais le risque d'emballement — « supprimer une fois un fichier important », « lancer une commande non voulue » — n'est pas nul.
D'où l'importance de la notion d'« isolement (sandbox) ». Quand vous donnez de forts droits à l'IA, faites-la tourner dans une boîte où les dégâts n'ont pas d'importance. Concrètement, enfermez-la dans un dossier de travail ou un conteneur dédié, sans accès aux données de production ni aux secrets. Ainsi, vous pouvez confier l'automatisation à l'IA l'esprit tranquille.
📦 « Essayer dans la boîte, la production en douceur » est le principe. Ne lancez pas l'exécution automatique de l'IA d'emblée sur l'environnement de production ou sur des données importantes. La méthode concrète d'isolement est détaillée dans le guide de configuration du sandbox de Claude Code. Sur la route débutant, pour cette section, savoir simplement « qu'il existe ce genre de garde-fou » suffit.
Publier — du code à la mise en ligne
Voici enfin la publication. « Publier », c'est prendre ce qui est dans votre ordinateur et le placer sur Internet pour que n'importe qui puisse l'ouvrir via une URL. C'est ce qu'on appelle déployer. Ça sonne compliqué, mais aujourd'hui, on met ça en ligne en quelques clics sur un service gratuit.
Le déroulé général tient en 3 étapes. La première publication d'un dev indépendant se fait très bien entièrement sur les offres gratuites. Dépenser viendra quand les utilisateurs se multiplieront.
Sauvegarder le code sur GitHub par exemple. N'oubliez pas d'exclure le fichier secret (.env). C'est la base de la publication.
Connectez GitHub à un hébergeur gratuit comme Vercel. Enregistrez les secrets comme variables d'environnement depuis le tableau de bord.
Le build se fait automatiquement en ligne et une URL publique est émise. Il ne reste qu'à la remettre à une personne.
✅ Même inachevé, publiez et montrez à une personne. « Il manque encore des fonctions », « le design est moyen » — repousser la publication avec ces pensées est la première cause de disparition des devs indépendants. 60 % suffisent. Allez jusqu'à envoyer l'URL publique à une personne de votre entourage. Son « ici, c'est peu pratique » vaut plus que 100 heures de doute.
La marche à suivre concrète — de la sauvegarde sur GitHub à la publication sur Vercel et au réglage des variables d'environnement — est expliquée captures à l'appui dans Créer avec Claude Code / Cursor et publier sur Vercel. Bloqué ? Demandez tel quel à l'IA « une erreur est apparue sur cet écran, que faire ? » et vous vous en sortez le plus souvent.
- Même seul, l'IA fait le relecteur. « Relève les bugs, entrées dangereuses et tests manquants » pour l'audit, puis corriger un par un.
- La sécurité, 3 minimums : secrets vers les variables d'environnement / protéger les données d'autrui / permissions au minimum.
- Ne jamais publier une clé secrète. Fuitée ? Pas de suppression mais révocation et régénération. Vérifier avec l'IA avant de publier.
- La publication (déploiement) se fait sur l'offre gratuite. Même inachevé, allez jusqu'à remettre l'URL à une personne.
Vous voilà arrivé à « créer et publier en sécurité ». Mais le vrai match commence ici. Le faire utiliser, l'améliorer, le rendre pérenne est la phase finale. Passons au chapitre 6, « Faire grandir — acquisition et monétisation ».