Si vous développez un logiciel, RAD peut le rendre déployable sur Google Cloud tel que vous le publiez, sans fork ni changement de licence. Si vous réalisez des prestations cloud, RAD peut publier vos propres modules Terraform et les déployer via une seule interface, avec une seule piste d’audit.
Deux lecteurs différents, deux offres différentes.
Open source ou open core, auto-hébergé, adossé à une édition commerciale ou à une offre de support. C’est dans la première heure d’auto-hébergement que les utilisateurs potentiels abandonnent. Lire la partie éditeurs →
Cabinet de conseil, agence ou revendeur, avec votre propre Terraform que vous réappliquez pour chaque client. La livraison est répétitive et la trace de qui a déployé quoi est éparpillée. Lire la partie prestataires →
Les deux parties reposent sur le même catalogue : plus de 350 options de déploiement couvrant plus de 180 applications et modules de plateforme, déployées dans un projet Google Cloud qui appartient au client final.
Pas en haut, mais là où quelqu’un qui veut déjà votre logiciel doit le mettre en place.
Le visiteur a lu la documentation, apprécié le produit et ouvert le guide de déploiement. Il se heurte ensuite à une base de données, un proxy inverse, TLS, un stockage objet et un compte de service, dont aucun n’est votre produit.
Une démo en conteneur d’une ligne montre à quoi ressemble l’interface. Elle ne dit pas si le logiciel tient dans votre cloud, sous vos règles, à côté de vos données — la question qui précède un achat.
Ceux qui vont au bout d’une installation manuelle en huit étapes sont les plus à même de l’exploiter gratuitement ensuite. Ceux qui abandonnent sont ceux qui auraient payé un support ou une offre hébergée.
L’intérêt est mondial, le paiement ne l’est pas. Un développeur parfaitement capable d’évaluer votre logiciel peut ne pas franchir l’étape de paiement qui en ferait un utilisateur, et encore moins un client.
RAD est un canal de déploiement, pas un accord de distribution. Rien ne change pour votre projet.
Pas de fork, pas de reconditionnement, pas de changement de licence, pas de copie embarquée de votre code. RAD déploie les artefacts que vous publiez déjà et, à chaque nouvelle version, nous mettons le module à jour en conséquence.
Rédiger le module, le maintenir face aux évolutions de Google Cloud et répondre aux questions de déploiement, c’est notre travail, pas le vôtre. Vos mainteneurs continuent de maintenir votre logiciel.
Il atterrit dans un projet Google Cloud qui lui appartient, en Terraform standard, et continue de fonctionner à l’identique même s’il ne se reconnecte jamais à RAD. L’état Terraform est stocké dans le Cloud Storage de RAD, et non dans le sien. Personne n’est enfermé dans une couche intermédiaire pour essayer votre logiciel.
Le catalogue propose plus de 60 solutions préconfigurées. Un logiciel inclus dans l’une d’elles est déployé par ceux qui sont venus pour l’ensemble : une équipe qui installe un service d’assistance ou une pile analytique, et qui exploite désormais votre projet au sein du parc demandé.
RAD accepte les paiements via Stripe et Flutterwave, et Flutterwave prend en charge la carte bancaire, le virement, l’USSD et le mobile money.
Les projets gérés par RAD tournent dans une région de chacune des huit zones géographiques, dont africa-south1, la seule région Google Cloud du continent africain.
Chaque entrée du catalogue dispose d’un guide de configuration qui documente les variables demandées par le formulaire de déploiement. Le site de documentation en compte plus de 520, ainsi qu’un atelier pratique, aboutissant à un déploiement fonctionnel, pour chacune des plus de 340 options d’application.
Quatre étapes. Aucune n’exige d’exclusivité, et vous pouvez vous arrêter à n’importe quel palier.
Nous créons un module pour votre logiciel, qui apparaît dans le catalogue avec les autres : formulaire guidé, coût en crédits affiché, journaux de build en direct et sorties publiées.
Vous examinez le module et confirmez qu’il reflète la façon dont votre logiciel doit être exploité. Valeurs par défaut, versions et variables exposées sont convenues avec vous, pas devinées.
Votre logiciel rejoint des solutions préconfigurées, déployé avec ce qui l’accompagne habituellement. Les paires câblées arrivent connectées ; les autres se relient à la main.
Des supports communs : l’atelier de déploiement, le guide de configuration et un parcours de votre documentation vers une installation fonctionnelle. Convenu par écrit, jamais présumé.
Nous construirons un déploiement de référence de votre logiciel et vous le montrerons avant tout engagement de votre part.
Vous avez déjà le Terraform. Ce qui vous manque, c’est un moyen de l’exécuter pour trente clients sans qu’il devienne trente variantes légèrement différentes.
Votre dépôt reste le vôtre. Une fois le rôle « Partenaire » attribué par un administrateur, vous installez l’application GitHub RAD Module Sync, et RAD synchronise vos modules à chaque push et toutes les heures. Il présente vos variables sous forme de formulaire guidé et les déploie via le même moteur que le reste du catalogue, avec les mêmes journaux de build, sorties et procédure de démantèlement. Les modules se gèrent dans GitHub ; la console est en lecture seule.
Un consultant junior déploie le modèle conçu par votre ingénieur principal, sans chaîne d’outils locale, sans identifiants sur un portable, sans étape non documentée dont seul quelqu’un se souvient. Le mode basique ne demande que les variables obligatoires, et un premier déploiement est toujours en mode basique ; l’ensemble complet s’ouvre lors d’une mise à jour, dès que le solde de crédits de l’utilisateur le couvre, que le projet lui appartienne ou soit géré par RAD.
Qui a déployé quoi, dans quel projet, quand, et pour quel coût en crédits. Les actions financières génèrent des enregistrements d’audit : ce que vous avez exécuté dans l’environnement d’un client relève d’une requête, pas d’un souvenir.
Sous ses règles d’administration, dans n’importe quelle région Google Cloud, en Terraform ordinaire qu’il peut lire et reprendre. À la fin de la mission, il ne se retrouve pas avec quelque chose que vous seul savez exploiter.
Toute personne détenant des crédits achetés, ainsi que chaque partenaire et administrateur, peut ouvrir un projet client depuis la vue « Projets clients » de « Environnements gérés » : le client accepte une invitation, RAD crée un projet de niveau Production, et vous alimentez un portefeuille client à partir de vos crédits achetés, puis le rechargez ou y prélevez au fil du travail. Le client vous paie, jamais RAD, et voit le projet sous « Gérés pour vous ». Si le portefeuille s’épuise, la facturation est suspendue au lieu de continuer ; une fois le travail terminé, vous remettez le projet au client, ou y mettez fin et supprimez ce qui a été déployé, et les crédits inutilisés du portefeuille vous reviennent.
Un module marqué public est référencé dans le catalogue dès sa synchronisation, sans étape d’approbation ; tout autre module reste privé, réservé à vous ou aux personnes qu’il désigne par e-mail. Déployer les modules d’un partenaire, y compris les vôtres, nécessite un accès au déploiement qu’un administrateur active pour chaque partenaire.
Les taux sont convenus avec vous par écrit.
Les déploiements d’un module publié par un partenaire sont facturés en crédits comme les autres : les frais de module que vous fixez dans le module lui-même, affichés avant que l’utilisateur ne confirme, plus un coût de build calculé sur la durée du provisionnement. Déployer votre propre module vous exonère des frais ; le coût de build s’applique toujours.
Votre part est calculée sur les frais de module payés en crédits achetés, jamais sur le coût de build, et indiquée dans l’onglet « Revenus des modules » de votre page « Crédits ». Le service financier enregistre chaque versement dans la plateforme, au taux en vigueur lors du paiement, et il apparaît dans votre section « Versements » avec les éventuels gains liés aux demandes de mise en place.
Les revenus de modules n’incluent pas les parrainages. Si vous orientez des clients vers RAD plutôt que de déployer pour leur compte, cela passe par le rôle distinct « Agent », attribué par un administrateur : une commission en numéraire sur les frais de module que vos utilisateurs parrainés paient en crédits achetés.
Les clients parrainés conservent leur propre compte, leur propre projet et leurs propres crédits. Rien dans cet arrangement ne vous place entre eux et leur infrastructure.
Des pourcentages que nous n’avons pas confirmés avec vous, ni aucune projection de revenus. RAD est en version bêta, et une progression de revenus sur la première année affichée sur une page partenaire serait un chiffre inventé.
Demandez-nous les conditions actuelles et nous vous enverrons les vraies, datées.
Deux brochures développent l’argumentaire : la proposition de partenariat pour les éditeurs open source, et l’opportunité de revenus pour les partenaires de services. Aucune ne contient de pourcentage que nous n’avons pas convenu avec vous.
Où en est l’écosystème aujourd’hui.
Les modules proviennent de dépôts Git, sont présentés sous forme de formulaires guidés, déployés par le même moteur et facturés via le même registre de crédits. C’est ainsi que fonctionnent déjà les plus de 350 options de déploiement existantes.
La plateforme et le catalogue sont en place et opérationnels. Nous débutons, nous n’avons aucun logo client à vous montrer, et nous n’allons pas en fabriquer.
Vous seriez le premier. Nous le disons ici, car vous l’apprendriez de toute façon dès le premier appel.
Google Cloud uniquement, et Terraform est le contrat : un module doit donc pouvoir s’exprimer en Terraform.
Sept options du catalogue ne peuvent pas être déployées dans un projet géré par RAD et exigent que le client fournisse le sien. RAD n’est pas la façon la moins chère d’exploiter une seule petite application.