ShipPad : Faire construire l'AI pour toi — pas juste avec toi

J’ai regardé une professeure de yoga décrire une idée d’app à Claude Code. Pas de background technique. Elle voulait un système de réservation avec des horaires de cours, des listes d’attente, et des paiements. Elle a tapé ce qu’elle voulait en anglais simple.

Dix minutes plus tard, elle avait un prototype fonctionnel.

Deux heures après, c’était en ligne sur Vercel.

C’est l’histoire que tout le monde raconte. Mais voilà la partie qu’on omet.

L’AI construit vite. Elle construit aussi dangereusement.

Donne à un utilisateur non-technique accès à Claude Code sans scaffolding et regarde ce qui se passe. Le code fonctionne. Il tourne. Il semble correct.

Puis tu regardes de plus près.

Les entrées utilisateur vont directement dans les requêtes de base de données. Les clés API finissent dans l’historique git. Il n’y a pas de tests, donc personne ne sait quand quelque chose casse. La mise en page mobile plante sur Android. Il n’y a pas de pattern d’authentification, donc l’app fait confiance à quiconque dit qu’il est connecté.

L’app de réservation de la professeure de yoga aurait fuit des données clients en moins d’un mois.

C’est le vrai problème. Les assistants AI sont extraordinairement capables. Ils construiront ce que tu décris. Mais ils ne savent pas ce que tu ne sais pas demander. Si tu ne sais pas ce qu’est une injection SQL, tu ne demanderas pas à Claude de la prévenir. Si tu ne sais pas ce qu’est une suite de tests, tu ne demanderas pas à Claude d’en écrire une.

Le résultat reflète la connaissance de la personne qui le guide. Et c’est exactement là où les utilisateurs non-techniques se font avoir.

ShipPad n’est pas un template

Soyons précis sur ce qu’est ShipPad, parce qu’il est facile de mal le comprendre.

Ce n’est pas un outil low-code. Tu écris toujours du code — Claude l’écrit, mais c’est du vrai code.

Ce n’est pas un template. Un template te donne des fichiers de départ. ShipPad te donne un système d’exploitation sur la façon dont Claude Code devrait se comporter dans ton projet.

Le cœur est un ensemble de fichiers structurés — des fichiers CLAUDE.md, des définitions de règles, des configurations de tests, des scripts de déploiement — qui disent à Claude exactement comment travailler dans cette base de code spécifique. Quels patterns suivre. Quelles limites ne jamais franchir. Quoi tester avant de prétendre que quelque chose est fait.

Quand tu ouvres un projet ShipPad et commences à parler à Claude, Claude sait déjà :

• Ne jamais mettre de secrets dans le code, toujours utiliser des variables d’environnement
• Toujours valider les entrées utilisateur avant de toucher la base de données
• Lancer les tests avant de dire que quelque chose est corrigé
• Utiliser ces commandes de déploiement spécifiques pour passer en production
• Suivre ces standards d’accessibilité lors de la construction de l’UI

Tu n’as pas besoin de savoir quoi que ce soit de tout ça. Claude le sait. Parce que le projet le lui a dit.

Comment ça marche vraiment

Le mécanisme principal est les fichiers CLAUDE.md. Claude Code les lit automatiquement quand il commence à travailler dans un projet. Ils sont en texte simple. Ils contiennent des règles écrites en langage naturel.

Un fichier de règles de sécurité pourrait dire : ne jamais hardcoder des clés API. Toujours utiliser des requêtes paramétrées. Ne jamais inventer son propre système d’authentification.

Un fichier de règles de tests pourrait dire : ne jamais dire “c’est fait” sans lancer les tests d’abord. Tester ce que l’utilisateur voit, pas l’état interne. Couvrir les chemins critiques à 100%.

Une config de déploiement gère la publication réelle — environnements de staging, protections de production, procédures de rollback.

Rien de tout ça n’est magique. C’est juste du contexte structuré qui dit à un assistant AI comment se comporter de façon responsable. L’insight, c’est que la plupart des gens qui construisent avec l’AI n’ont pas ce contexte, et ils ne savent pas qu’ils en ont besoin.

ShipPad le leur package.

À quoi ça ressemble en pratique

Retour à la professeure de yoga.

Elle a ouvert un projet ShipPad, décrit son système de réservation, et a commencé à construire avec Claude. Voici ce à quoi elle n’a pas eu à penser :

Claude a automatiquement utilisé des requêtes paramétrées quand il a construit la couche base de données. Il a généré des placeholders de variables d’environnement pour la clé API Stripe au lieu de mettre la clé dans le code. Il a écrit des tests pour le flux de réservation avant de marquer cette fonctionnalité comme complète. Il a utilisé une librairie d’authentification établie au lieu de construire quelque chose de custom.

Elle n’a rien demandé de tout ça. Les règles du projet l’ont fait.

Ce sur quoi elle a pu se concentrer, c’était le vrai produit. Les types de cours, les politiques d’annulation, la logique de liste d’attente qu’elle voulait. Le truc de builder.

Autre exemple : un chef de produit qui voulait un dashboard interne pour les métriques de son équipe. Pas de développeur. Il a utilisé ShipPad, passé un weekend à construire avec Claude, et a publié quelque chose de réel. La config de déploiement signifiait qu’il pouvait pousser des mises à jour avec une seule commande. Les budgets de performance signifiaient que le dashboard restait rapide même quand il ajoutait plus de graphiques.

Ce ne sont pas des cas exceptionnels. C’est ce qui se passe quand tu donnes aux gens le bon scaffolding.

La vue d’ensemble

Le vibe coding — construire des logiciels en décrivant ce que tu veux, en laissant l’AI le traduire en code fonctionnel — c’est réel. Ce n’est pas une tendance qui va disparaître. Plus de gens vont construire des logiciels de cette façon, pas moins.

La question n’est pas de savoir si les personnes non-techniques devraient construire avec l’AI. Elles le font déjà. La question est de savoir si elles le font en sécurité.

En ce moment, la plupart ne le font pas. Pas parce qu’elles sont imprudentes, mais parce qu’elles ne savent pas ce qu’elles ne savent pas. Elles construisent quelque chose qui fonctionne et le publient sans comprendre la surface d’attaque qu’elles viennent de créer.

ShipPad est ma réponse à ça. Les garde-fous devraient venir avec le projet. Les règles de sécurité, les patterns de tests, l’infrastructure de déploiement — tout ça devrait être là dès le début, configuré correctement, pour que construire avec l’AI produise des logiciels vraiment sûrs à faire tourner.

Ce qui arrive

Je construis ShipPad comme un ensemble de project starters — différentes configurations pour différents types de projets. Web apps, outils internes, landing pages avec du contenu dynamique, produits mobile-first.

Chacun est livré avec l’infrastructure complète : règles de sécurité calibrées pour ce type de projet, configuration de tests prête à l’emploi, config de déploiement pour les cibles d’hébergement les plus courantes.

L’objectif est simple. Quiconque a une idée et Claude Code devrait pouvoir construire quelque chose de réel sans accidentellement construire quelque chose de dangereux.

Si tu construis avec l’AI et que tu n’as pas de garde-fous, tu construis sur du sable. ShipPad te donne les fondations.