Les questions auxquelles les autres pages ne pouvaient pas répondre sans perdre le fil.
Commencez ici si vous ne nous connaissez pas encore.
RAD est une plateforme de déploiement pour Google Cloud. Choisissez parmi plus de 350 options de déploiement (plus de 180 applications et modules de plateforme) et RAD la provisionne dans votre propre projet ou dans un projet qu’il crée.
Google Cloud, et rien d’autre. C’est une limite délibérée : les règles d’administration, l’IAM, le réseau et les garde-fous que met en place RAD sont propres à Google Cloud. Si votre parc est ailleurs, RAD n’est pas le bon outil.
Le Rapid Application Development est une méthodologie des années 1990 axée sur le prototypage itératif. Ici, RAD déploie sur Google Cloud des modèles d’infrastructure prêts à l’emploi, et le D signifie « deployment » (déploiement).
Un module est une option déployable : une application dans un mode d’exploitation, écrite en Terraform et accompagnée d’un formulaire guidé. Plus de 350 options couvrent plus de 180 applications et modules de plateforme, car la plupart des applications existent à la fois en variante Cloud Run et GKE. Voir le catalogue.
Une solution est un ensemble préconfiguré d’applications déployées dans un même projet Google Cloud ; il en existe plus de 60. Les membres sans prérequis sont provisionnés quatre à la fois ; celui qui consomme les sorties d’un autre attend. La destruction se fait dans l’ordre inverse. Fonctionnement des solutions.
Les questions qu’une équipe plateforme pose en premier.
Le vôtre, par défaut. RAD déploie dans un projet qui vous appartient, sous les règles de votre organisation, que RAD ne peut pas assouplir, et vous gardez accès à toutes les régions proposées par Google. Sans compte Google Cloud, RAD peut à la place en créer et en encadrer un pour vous, dans l’un de quatre niveaux. Dans un projet géré, vous achetez des crédits, qui sont imputés sur ses coûts Google Cloud.
Oui. Les ressources d’un projet qui vous appartient continuent de tourner : elles sont à vous. Un projet géré par RAD est différent — il dépend du compte de facturation de RAD, et RAD en suspend la facturation dès que votre solde de crédits achetés passe sous le minimum de son niveau. L’état Terraform reste chez RAD et, passé la période de conservation, un enregistrement inactif est supprimé avec lui ; vos ressources, non.
Non. Le code source des modules est du Terraform ordinaire, et les ressources sont des ressources Google Cloud ordinaires dans un projet qui vous appartient. Le fichier d’état et son backend pointent vers le bucket Cloud Storage de RAD. La plupart des modules proviennent de dépôts partenaires, qui sont privés. RAD publie un dépôt qui lui est propre à titre d’exemple, et pourra en publier d’autres à sa discrétion.
Non. RAD provisionne l’infrastructure puis s’efface. Le trafic atteint directement vos ressources Google Cloud ; il ne passe pas par RAD, et une indisponibilité de RAD ne rend pas votre déploiement indisponible. Ce qui cesse de fonctionner, c’est notre console, pas ce que vous avez déployé, qui continue de servir le trafic exactement comme avant.
Tout ce que RAD facture, et ce que Google facture à sa place. Tous les détails sur la page des tarifs.
Deux composantes : des frais de module, prélevés au premier déploiement réussi, et un coût de build pour le temps de provisionnement. Un dollar US vaut 10 crédits ; la durée de build coûte 6 crédits de l’heure, arrondie au supérieur par build. Les mises à jour sont sans frais de module. Les ressources Google Cloud sont facturées au projet.
Rien n’est facturé. Un nouveau déploiement qui échoue ou est annulé n’entraîne ni ses frais de module ni sa durée de build, pas plus qu’une mise à jour ou une destruction échouée. L’équipe financière peut modifier ce réglage ; les deux facturations sont désactivées dans la version actuelle. Vous pouvez lire le même journal de build qu’un ingénieur.
Cela dépend du solde, parmi les quatre, où ils se trouvent. Les crédits offerts sont renouvelés chaque mois et ne se cumulent pas. Les crédits événement expirent à la date propre à leur code. Les crédits d’abonnement sont reportés. Les crédits achetés n’expirent jamais. Les dépenses puisent d’abord dans le solde qui expire le plus tôt.
Vous recevez 300 crédits à l’inscription puis 100 chaque mois, sans moyen de paiement requis. Les utilisateurs gratuits déploient dans leur propre projet Google Cloud et paient directement Google pour les ressources qu’ils créent.
Via Stripe ou Flutterwave, qui acceptent à eux deux carte, virement, USSD et paiement mobile. RAD ne traite jamais vos données de carte : le paiement a lieu sur la page hébergée du prestataire, crédits attribués dès sa confirmation.
Oui. L’onglet « Transactions de projets » de la page « Crédits » ventile la refacturation par projet Google Cloud, sur la période de votre choix, avec les crédits débités et le coût cloud correspondant à chacun.
L’option pour qui n’a pas de compte Google Cloud.
Un projet Google Cloud que RAD crée et encadre pour vous, selon quatre niveaux — Sandbox, Développement, Production et Lab —, chacun avec son propre jeu de règles. Choisissez Sandbox, Développement ou Production, dans l’une de huit régions.
Dans les niveaux Sandbox et Lab sont interdits : IP externes, réseaux par défaut, port série des VM, clés de compte de service, buckets publics et IP publiques Cloud SQL ; services limités à une liste autorisée. Développement en assouplit trois, chacun avec un contrôle compensatoire.
Chaque projet géré comporte un budget Google Cloud mensuel qui alerte à l’approche puis au dépassement du montant. Un budget notifie, il ne bloque pas : il n’arrêtera aucun appel d’API, et l’augmenter n’autorise aucune dépense supplémentaire.
Parce qu’un déploiement en projet géré par RAD en compte trois : le projet, les services partagés de vos applications, puis votre application. L’écran de confirmation chiffre toute la chaîne avant validation. Aujourd’hui, les deux premiers sont sans frais de module, seulement leur durée de build.
RAD est conçu pour désactiver la facturation du projet géré jusqu’à ce que le solde soit rechargé, puis pour la réactiver. La vérification a lieu toutes les quinze minutes et n’annule qu’une suspension appliquée par RAD lui-même, jamais celle d’un administrateur.
Les mécanismes, décrits simplement.
Vous, et les administrateurs de la plateforme. Un formateur peut voir et arrêter les environnements d’atelier de ses propres sessions, secrets exclus — jamais ce que vous avez déployé vous-même. Les rôles sont déterminés côté serveur à partir des fiches utilisateur enregistrées, jamais de ce qu’envoie votre navigateur.
Non. L’accès du support est restreint et temporaire : un agent ne voit les déploiements d’un client que tant qu’un ticket qui lui est attribué est ouvert, et sa clôture met fin à l’accès — immédiatement dans la console, en cinq minutes au plus sur l’API. Le support n’a pas accès aux valeurs de configuration brutes ni aux sorties.
Dans le bucket Cloud Storage de RAD, pas dans le vôtre : le projet et les ressources sont à vous, le fichier d’état est à nous, et le produit ne propose aujourd’hui aucun téléchargement. Un enregistrement n’est supprimé qu’après la période de conservation et un e-mail d’avertissement, et les projets gérés par RAD sont entièrement exclus de ce nettoyage.
Non, et nous n’en revendiquons aucune. Les mécanismes : rôles déterminés côté serveur, secrets dans Google Secret Manager, identités de service au moindre privilège, garde-fous par règles d’administration sur les projets gérés, et enregistrements d’audit sur les actions impliquant de l’argent. RAD ne détient aucune attestation formelle.
Accès anticipé. Tout savoir pour les formateurs.
Un formateur crée une session depuis la vue « Sessions de lab » de « Environnements gérés », sur la page Solutions : des participants partageant un même créneau, une allocation de crédits chacun et une région. Une seule action déploie le même module ou la même solution dans le projet d’atelier propre à chaque participant, supprimé à la fin de son temps.
Le formateur choisit à la création de la session et ne peut plus changer ensuite. Soit il finance chaque place avec des crédits achetés, soit chaque participant achète la sienne, conservée jusqu’au démarrage de son chrono. Dans ce second cas, le formateur peut tout de même payer la place de n’importe quel participant, par exemple quelqu’un qui l’a réglé en espèces ou dont la banque est refusée par le prestataire de paiement. Les crédits inutilisés reviennent au formateur à la clôture de la session.
Les environnements d’atelier de ses propres sessions, avec l’état et les journaux de build ; jamais les déploiements personnels d’un participant. Un formateur ne peut pas lire les secrets, les variables de configuration ni les mots de passe générés d’un déploiement d’atelier ; ses sorties sont affichées sans aucune valeur sensible, afin que le formateur puisse accéder à l’URL de l’application.
La section que les sceptiques consultent en premier.
RAD est en version bêta. Le catalogue et le moteur de déploiement sont en place et opérationnels ; ils configurent des ressources cloud dans votre projet ou dans un projet géré par RAD qui vous est facturé. Ces éléments sont prêts pour la production ; les nouveautés sont signalées en accès anticipé.
Tout ce pour quoi utiliser un logiciel en version bêta constitue en soi le risque : une charge de travail exigeant une attestation de conformité que nous ne détenons pas, ou un lancement qui ne tolère aucune surprise. Testez-le dès aujourd’hui en déployant un seul module dans votre propre projet, et jugez sur pièce.
Parce que chacun compte quelque chose qui existe, et que la plupart sont vérifiables sans compte : le catalogue est consultable, et les ateliers comme les guides de modules ne nécessitent aucune connexion. Aucun ne compte d’utilisateurs, de chiffre d’affaires ni de croissance.
Trois réponses, puis à vous d’essayer.
Inscrivez-vous sur radmodules.dev : 300 crédits offerts, sans moyen de paiement. La connexion mène au catalogue de modules ; tant que vous détenez des crédits achetés, au « Catalogue de solutions », et « Concevoir une solution par IA » se débloque : quatre questions qui renvoient un ensemble d’applications chiffré.
Non. « Concevoir une solution par IA » demande ce que les utilisateurs doivent pouvoir faire, où cela s’exécute, dans quelle région du monde et comment le nommer, puis déduit le reste. Il n’ouvre le formulaire complet que si quelque chose requiert votre intervention, comme un identifiant.
Non. Si vous en avez un, RAD déploie dans votre projet et vous payez directement Google pour les ressources. Sinon, RAD peut en créer et en encadrer un, et les dépenses Google Cloud sont prélevées sur votre solde de crédits.
Utilisez le formulaire de contact ; une personne y répond. Pour aller plus loin techniquement, la documentation propose plus de 340 ateliers pratiques et plus de 520 guides de configuration de modules, sans aucune connexion requise. Commencez par la page des ressources.