Une solution, ce sont plusieurs applications déployées dans un même projet Google Cloud, en une seule unité ordonnée selon leurs dépendances. Choisissez l’une des plus de 60 solutions préconfigurées, décrivez votre besoin pour que RAD la compose, ou répondez à quatre questions et obtenez-la composée, nommée et chiffrée.
Tout ce qui se déploie se trouve sur une seule page du produit, sous forme d’onglets — Concevoir une solution par IA, Catalogue de solutions (filtré sur « Tout », « Mes solutions », « Solutions RAD » ou « Modules RAD ») et Environnements gérés, qui regroupe les sessions d’atelier et les projets clients lorsqu’ils sont activés, plus une vue Gérés pour vous dès que quelqu’un en exécute une pour vous. Si vous vous connectez avec des crédits achetés, vous arrivez sur la vue « Tout » du « Catalogue de solutions ». Le catalogue mono-application est une vue du « Catalogue de solutions » plutôt qu’une destination à part ; son adresse propre fonctionne toujours, si bien que les liens et favoris existants restent valides.
La plupart des outils de déploiement installent une application. Les solutions RAD installent un ensemble fonctionnel dans un même projet en une seule confirmation, plusieurs à la fois, et chaque membre n’attend que celui dont il a besoin des sorties.
Chaque membre est un module RAD ordinaire, déployé en Terraform standard dans un projet Google Cloud qui vous appartient ou dans un projet que RAD gère pour vous. L’état Terraform de chaque membre est conservé dans le bucket Cloud Storage de RAD, pas dans votre projet.
Le catalogue est une voie. L’autre consiste à dire, avec vos propres mots, ce que vous cherchez à construire. RAD parcourt le catalogue de modules, propose une combinaison en justifiant chaque choix, et enregistre le résultat comme votre propre solution — privée à votre compte, et déployée par exactement le même pipeline qu’une solution préconfigurée.
RAD ne connecte deux membres que s’il existe déjà une connexion connue entre ces deux applications. Sinon, il l’indique sur la carte plutôt que d’en inventer une, et les membres se déploient quand même.
Composer et déployer supposent encore que vous sachiez ce que sont un niveau, un tag de région et une vague. Le parcours guidé ne suppose rien de tout cela : quatre questions en langage courant, et il renvoie un ensemble d’applications fonctionnel, nommé et chiffré. C’est Concevoir une solution par IA, le premier onglet de la page Solutions, et il nécessite des crédits achetés ; sans eux, il apparaît verrouillé, avec un bouton Acheter des crédits.
Les quatre réponses préremplissent le formulaire de déploiement lui-même — le projet, le niveau, la région et le nom arrivent déjà définis, au lieu d’un formulaire qui s’ouvrirait sur ses propres valeurs par défaut en écrasant discrètement vos réponses. Répondre en langage courant puis se voir reposer la question, sans restriction, serait pire que de ne jamais la poser.
Si tout a reçu une réponse, vous obtenez un récapitulatif Prêt à déployer plutôt qu’un formulaire. Deux cas y mettent fin : une application qui exige un identifiant, et tout paramètre obligatoire que les quatre questions ne couvrent pas. L’entretien ne transmet aucun secret, et ne fait pas passer un champ pour facultatif simplement parce qu’il ne l’a pas demandé.
Déployer une seule application implique rarement un seul déploiement — un socle partagé doit parfois être créé d’abord. L’estimation chiffre toute la chaîne en un seul appel et distingue ce qui est facturé tout de suite de ce qui est compté pendant le déploiement. Un solde minimum, le cas échéant, apparaît comme une somme que vous devez détenir, jamais ajoutée au total comme une somme dépensée.
Le parcours guidé explore et chiffre ; il ne déploie pas par une autre voie. L’ensemble qu’il produit est une solution personnalisée ordinaire, provisionnée par le même pipeline que toutes les autres solutions de cette page.
Six applications dont une entreprise de cinq à cinquante personnes a besoin pour vendre et se faire payer. Un formulaire, une confirmation, six déploiements dans un même projet.
Le système de référence pour les clients, devis, commandes et le plan comptable. Tout le reste de la suite s’articule autour.
Émet et relance les factures à partir des clients et commandes gérés dans le socle ERP.
Le temps saisi par client et par projet, pour le travail facturé à l’heure plutôt qu’au livrable.
Contrats et bons de commande signés sans abonnement à l’enveloppe. Documenso est l’alternative proposée si vous la préférez.
Le stockage documentaire derrière tout ce qui précède, dans le même projet plutôt que sur le drive grand public de quelqu’un d’autre.
En dernier, car il renvoie vers les cinq autres. Rien ne câble cette connexion pour vous : vous lui indiquez leurs adresses une fois qu’ils tournent.
Les solutions proposent des alternatives nommées lorsqu’un substitut existe. Ici, Dolibarr peut être remplacé par Odoo ou EspoCRM, sans rien changer au reste de l’ensemble.
Deux choses retiennent un membre : le socle partagé, si le projet et ses services partagés sont créés dans le cadre de ce déploiement, et un producteur dont le membre a besoin des sorties Terraform. Tout le reste démarre dès votre confirmation.
Toute la solution est enregistrée d’un coup, crédits réservés en une seule somme. Un membre qui doit attendre nomme les déploiements requis ; le reste est mis en file aussitôt.
Ni sur une étape, ni sur le membre qui le précède. Il est libéré dès que tous les déploiements qu’il nomme ont réussi. Si l’un échoue, ce membre est annulé et les autres continuent.
Les membres sans attente sont provisionnés en parallèle, jusqu’à quatre à la fois par défaut, plutôt qu’à la suite : une solution de six applications n’enchaîne pas six déploiements.
Le coût en crédits de tous les membres est réservé en une seule somme avant le premier déploiement : une solution ne reste jamais à moitié construite faute de crédits.
Les paires producteur-consommateur sont interconnectées par la plateforme. Dans les autres solutions, chaque connexion entre membres est une étape à réaliser vous-même une fois le déploiement terminé.
Lorsqu’une paire est interconnectée, le producteur publie de vraies sorties Terraform : une URL de service, une adresse interne au cluster, un point de terminaison d’API. À la fin de son déploiement, ces valeurs sont copiées dans la configuration du consommateur avant sa construction, sous forme de variable d’environnement ou de variable Terraform typée.
Les informations de connexion d’Elasticsearch sont inscrites dans la configuration de RAGFlow et de Zammad dès qu’Elasticsearch a terminé. Tous deux l’utilisent comme back-end de recherche.
Le moteur d’exécution des modèles et la passerelle placée devant transmettent tous deux leurs points de terminaison à l’interface de chat, qui dispose ainsi de modèles dès le premier chargement.
L’adresse interne au cluster de la base analytique, la base, l’utilisateur et le secret du mot de passe sont inscrits dans la configuration de Plausible. Plausible vérifie au moment du plan qu’il dispose d’un ClickHouse où écrire : cette solution ne peut donc pas être appliquée sans l’interconnexion.
L’adresse du serveur d’accueil Matrix est transmise au client, qui ne serait sinon qu’une application web pointant vers le vide.
Le serveur de CI reçoit l’adresse de l’hébergeur de code source à partir duquel il construit. L’enregistrement de l’application OAuth côté Gitea reste à votre charge, ce que la solution indique dans ses notes post-déploiement.
Partout ailleurs, connecter les membres vous revient. Les membres d’une solution arrivent dans un même projet, sur un même socle partagé, avec une seule réservation de crédits et dans un ordre qui respecte les dépendances. Ils n’arrivent pas intégrés.
Certaines solutions comportent des notes post-déploiement écrites pour le travail restant : connecter Nextcloud à ONLYOFFICE, enregistrer l’application OAuth Gitea dont Woodpecker a besoin, ajouter VictoriaMetrics et Loki comme sources de données dans Grafana. Les autres s’en remettent à la configuration propre à chaque application.
Sa place dans la bêta. L’interconnexion automatique est l’une des parties les plus récentes de RAD ; nous la décrivons donc comme conçue pour connecter ces paires. Une fois une solution terminée, vérifiez les valeurs dans la configuration de chaque membre avant de vous y fier.
Détruire un environnement dans le mauvais ordre, c’est s’exposer à des démantèlements en échec et à des ressources dont personne ne sait rendre compte.
Supprimer une solution demande à chaque membre de partir. Un prérequis n’est pas démantelé quand son compteur de références tombe à zéro : cela signifie seulement que ses dépendants ont été invités à partir. Son démantèlement reste en attente jusqu’à ce qu’ils soient tous dans un état final.
Un dépendant dont la destruction échoue libère quand même ce dont il dépend. Attendre un succès bloquerait indéfiniment le prérequis en cours de suppression, au lieu de terminer le démantèlement et de vous montrer le membre en échec.
Avant de refuser de détruire un élément parce que d’autres déploiements en dépendent, RAD résout chaque référence, ne bloque que sur celles qui existent encore, puis réécrit la liste. Une référence obsolète ne devient pas un blocage permanent.
Plus de 60 solutions, regroupées selon leur usage plutôt que selon leur technologie. Deux exemples nommés pour chacune.
| Catégorie | Exemples de solutions | Applications incluses |
|---|---|---|
| Opérations et back-office | Small Business Suite · Integrated ERP Platform | Dolibarr, Invoice Ninja, Kimai, Odoo, Metabase, OnlyOffice |
| Ventes, marketing et relation client | CRM & Sales Operations · Marketing Automation Suite | Twenty, Cal.com, Listmonk, Mautic, Matomo, n8n |
| Présence web, contenu et commerce | Headless Content Platform · E-commerce Storefront | Directus, Umami, Medusa, Payload, Matomo |
| Travail numérique et collaboration | Team Workspace · Secure Team Communications | Nextcloud, OnlyOffice, Mattermost, Synapse, Element, Vaultwarden |
| Plateforme de développement et DevOps | Source Control & CI/CD · Observability & On-call | Gitea, Woodpecker, Grafana, Loki, Uptime Kuma, GlitchTip |
| Données, analytique et BI | Analytics Warehouse · Self-service BI | ClickHouse, Superset, Metabase, NocoDB, CloudBeaver |
| IA et automatisation | Private AI Assistant · Enterprise RAG & Document Intelligence | Ollama, LiteLLM, OpenWebUI, Qdrant, Elasticsearch, RAGFlow |
| Identité, sécurité et zero trust | SSO Foundation · Zero-trust Network & DNS | Keycloak, Passbolt, Infisical, Headscale, AdGuard Home |
| Exploitation IT et gestion des services | IT Service Desk · Monitoring & NOC | Zammad, Snipe-IT, BookStack, Uptime Kuma, Netdata, Gatus |
| Éducation et formation | Learning Management Platform · Developer Training Lab | Moodle, Nextcloud, Element, code-server, Gitea |
| Solutions sectorielles | Clinic & Practice Management · NGO & Nonprofit Operations | OpenEMR, Cal.com, Paperless, Dolibarr, LimeSurvey |
| Cloud personnel, médias et loisirs | Personal Cloud · Digital Library | Nextcloud, Immich, Vaultwarden, Calibre-Web, Komga, Audiobookshelf |
Toutes sont prêtes et sélectionnables. Voir le catalogue complet des modules — plus de 350 options de déploiement couvrant plus de 180 applications et modules de plateforme.
Les mêmes frais de module que pour déployer chaque application séparément, moins une remise groupée qui augmente avec la taille de la solution.
Les frais de chaque membre s’affichent sur l’écran de confirmation, ligne par ligne, avec la remise appliquée et le solde qui en résulte, avant tout provisionnement. Lorsque RAD crée le projet et ses services partagés, ceux-ci sont chiffrés sur le même écran. Dans la version actuelle, un déploiement en échec n’est pas facturé du tout, ni frais de module ni coût de build ; il s’agit d’un paramètre défini par le service Finance, pas d’une règle figée.
Le coût de build est calculé d’après la durée réelle du provisionnement, et un déploiement prend en moyenne 19 minutes environ. Les estimations sont arrondies à l’unité supérieure, comme la facturation.
Le même environnement, une fois par participant, depuis une seule session d’atelier.
Un formateur lance une session d’atelier depuis la vue « Sessions de lab » de « Environnements gérés », sur la page Solutions : une promotion nommée qui partage une plage horaire, une région et une enveloppe de crédits par participant. Choisissez un module ou une solution multi-applications : il est construit en une seule action dans le vrai projet Google Cloud de chaque participant, dans le dossier propre au niveau Lab, avec les garde-fous les plus stricts que RAD applique.
Le payeur est fixé à la création de la session : le formateur finance toutes les places avec des crédits achetés, ou chaque participant achète la sienne. Les crédits non utilisés par les participants reviennent au formateur à la clôture de la session ; une place dont le chrono ne démarre jamais est remboursée à qui l’a payée. Lorsque le temps ou les crédits d’un environnement sont épuisés, sa facturation est coupée et son projet supprimé.
Les sessions d’atelier sont en accès anticipé. Nous recherchons des partenaires pilotes.
Choisissez une solution, répondez aux questions qui varient d’une installation à l’autre, et regardez-la se construire dans un projet qui vous appartient.
Google Cloud uniquement. Chaque module est du Terraform. RAD permet de déployer un environnement encadré sans en écrire le code d’infrastructure.