Revally · Création de produit · IA et delivery
Revally : construire son propre SaaS à trois fondateurs avec l’IA
Après un lancement en marque blanche, Revally construit sa plateforme pour maîtriser son expérience, ses données et ses workflows. L’IA aide à développer le produit ; le CTO relit et teste chaque changement.
Retour d’expérience · Cofondateur et CTO
Tech Lead et développeur TypeScript/Next.js chez Byrds Consulting.
Je suis l’un des trois cofondateurs de Revally et j’en assure la direction technique depuis début 2026. Sans équipe de développement dédiée, nous utilisons l’IA pour produire les premières implémentations. Mon temps de revue reste la limite : chaque changement doit être assez petit pour être compris, testé et maintenu.
Le contexte réel
Trois cofondateurs, dont un CTO
Revally aide les restaurants, bars, pharmacies et autres établissements à piloter leur présence en ligne. Le produit réunit le référencement local, la diffusion des informations vers plus de 50 plateformes, la gestion des avis, les contenus pour les réseaux sociaux et des fonctions assistées par IA.
Depuis le début de 2026, l’un des trois cofondateurs assure également la direction technique. L’entreprise ne dispose pas d’une équipe technique dédiée.
Au démarrage, une solution partenaire en marque blanche a permis de lancer le service et d’apprendre au contact du marché. Depuis, l’entreprise construit sa propre plateforme afin de maîtriser l’expérience, les données et les workflows qui la différencient.
La contrainte fondatrice
Produire davantage avec l’IA sans accumuler du code que le CTO ne peut ni relire ni maintenir.
- Faire évoluer le produit propriétaire sans interrompre le service existant.
- Garder chaque changement assez petit pour être compris, testé et repris par le CTO.
- Automatiser les contrôles mécaniques sans déléguer les choix produit ni le merge.
La transition produit
Passer de la marque blanche au produit propriétaire
Le socle partenaire a validé un besoin avant d’engager la construction complète. La nouvelle plateforme n’a donc pas pour objectif de reproduire chaque écran existant. Elle reprend progressivement les capacités pour lesquelles Revally doit maîtriser le modèle de données, l’expérience et le rythme d’évolution.
Le code peut être proposé rapidement, mais le temps de revue du CTO reste limité. Chaque tâche doit donc être assez précise pour qu’il puisse vérifier le diff, tester le comportement et reprendre l’implémentation si nécessaire.
Différenciation
Quelles données, expériences et fonctions IA Revally doit-elle maîtriser plutôt que déléguer au fournisseur historique ?
Continuité
Comment construire la nouvelle plateforme sans interrompre les usages encore servis par la marque blanche ?
Capacité de revue
La pull request poursuit-elle un objectif unique que le CTO peut réellement relire et tester ?
Contrôles avant merge
Chaque PR dispose-t-elle de checks, d’une image Docker construite par la CI et d’une preview isolée ?
L’infrastructure fournit des éléments concrets pour examiner chaque modification : un diff limité, des contrôles automatisés, une image Docker et une preview. Le CTO peut ainsi concentrer sa revue sur le comportement du produit, l’architecture et les risques.
Le socle technique
Rendre chaque changement vérifiable avant le merge
La plateforme repose sur Next.js 16 et l’App Router. Les workflows durables s’appuient sur le Workflow SDK de Vercel et s’exécutent sur l’infrastructure de Revally. L’application est empaquetée avec Docker, déployée par Coolify et hébergée chez OVH en France.
GitHub Actions exécute le lint, le typecheck, les tests, le build Next.js et la construction de l’image Docker. Coolify déploie ensuite une preview propre à la pull request. Le diff, les résultats des checks et cet environnement donnent au CTO une base concrète pour la revue.
PR mono-tâche
Objectif, critères d’acceptation et limites définis par les fondateurs avant la production de code.
Next.js 16 et Workflow
Socle App Router, fonctionnalités produit et workflows durables mis en œuvre avec une forte assistance de l’IA.
GitHub Actions et Docker
Lint, typage, tests et build exécutés pour chaque pull request, avec une image Docker construite par la CI.
Preview Coolify sur OVH
Un environnement isolé par changement pour vérifier le comportement avant le merge.
Les conditions avant merge
- Une seule tâche, avec un périmètre validé.
- Lint, typecheck, tests, build Next.js et image Docker réussis.
- Une preview disponible sur le commit courant de la PR.
- Une revue automatique terminée, sans point bloquant.
- Une décision humaine après lecture du diff et test du parcours.
Cette liste résume les conditions de revue ; elle ne reproduit pas le fichier GitHub Actions. Le CTO peut demander des corrections même lorsque tous les contrôles automatiques passent.
Le parcours d’une modification
De l’idée au merge, quatre points de contrôle
L’IA intervient dans le triage, la préparation, le développement et la revue. Un fondateur fixe le résultat attendu, et le CTO reste responsable du merge dans la branche principale.
01
Cadrer une seule tâche
Un fondateur formule l’objectif, les critères d’acceptation et ce que la pull request ne doit pas modifier.02
Produire un premier jet
L’IA propose l’implémentation, les tests et les ajustements. La majorité du code peut venir de ce premier travail réalisé avec son aide.03
Exécuter les garde-fous
GitHub Actions vérifie lint, typage, tests, build et image Docker. Coolify déploie une preview propre à la pull request.04
Relire puis décider
Les revues automatiques signalent des problèmes potentiels. Le CTO examine le diff, teste le parcours dans la preview, puis décide de merger ou demande des corrections.
Le temps déjà consacré à une proposition ne justifie pas de la conserver. Si le résultat est peu convaincant, l’implémentation est reprise ou abandonnée.
Ce qui change réellement
Produire les premiers jets, puis prendre le temps de les relire
La majeure partie du premier jet est produite avec l’aide de l’IA, mais la revue humaine reste le facteur limitant. Les contrôles automatisés filtrent les erreurs mécaniques ; le CTO réserve son temps au comportement, à l’architecture et aux conséquences produit.
Ce que le dispositif permet aujourd’hui
Ces résultats décrivent le fonctionnement actuel ; ils ne constituent pas un benchmark de productivité.
- Le produit propriétaire est développé par les trois fondateurs, sans équipe de développement dédiée.
- Le code écrit à la main et le code produit avec l’aide de l’IA passent par les mêmes contrôles GitHub Actions.
- Chaque pull request possède un environnement Coolify avant son merge.
- Les revues automatiques signalent des points à vérifier avant que le CTO ne décide de merger.
Décider de reprendre ou d’abandonner une proposition
Le dépôt, la CI et les previews permettent d’examiner chaque proposition. Si je ne comprends pas suffisamment le changement pour le maintenir, il doit être repris avant livraison.
Produit et documentation technique
- Revally. Site produit. Positionnement public, secteurs couverts et fonctionnalités de présence locale, d’avis, de contenus et d’IA.
- Workflow SDK. Vercel. SDK utilisé pour construire des workflows durables et observables en TypeScript.
- GitHub Actions. GitHub Docs. Documentation de référence pour les contrôles et automatisations exécutés sur les pull requests.
- GitHub Preview Deploy. Coolify Docs. Documentation des environnements isolés créés à partir des pull requests.
- Self-hosting. Documentation Next.js. Contraintes officielles du déploiement autonome d’une application Next.js.