Une chaîne de delivery pour construire Revally avec l’IA

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.

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.

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.

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.

type RequiredCheck = 'lint' | 'typecheck' | 'tests' | 'build' | 'docker'
type CheckStatus = 'pending' | 'passed' | 'failed'
type ReviewFinding = { blocking: boolean }
type AutomatedReview = {
    status: CheckStatus
    findings: ReviewFinding[]
}
type Preview = {
    status: CheckStatus
    url?: string
    commitSha: string
}

type PullRequest = {
    headSha: string
    scope: {
        kind: 'single-task' | 'multi-task'
        check: CheckStatus
    }
    checks: Record<RequiredCheck, CheckStatus>
    preview: Preview
    automatedReview: AutomatedReview
    humanDecision: 'pending' | 'merge' | 'request-changes'
}

const requiredChecks: RequiredCheck[] = [
    'lint', 'typecheck', 'tests', 'build', 'docker',
]

const canMerge = (pullRequest: PullRequest) => {
    const allChecksPassed = requiredChecks.every(
        (name) => pullRequest.checks[name] === 'passed',
    )

    return (
        pullRequest.scope.kind === 'single-task' &&
        pullRequest.scope.check === 'passed' &&
        allChecksPassed &&
        pullRequest.preview.status === 'passed' &&
        Boolean(pullRequest.preview.url) &&
        pullRequest.preview.commitSha === pullRequest.headSha &&
        pullRequest.automatedReview.status === 'passed' &&
        !pullRequest.automatedReview.findings.some(
            ({ blocking }) => blocking,
        ) &&
        pullRequest.humanDecision === 'merge'
    )
}

Ce type illustre le processus ; il ne reproduit pas le fichier GitHub Actions. Le périmètre doit être validé, tous les checks au vert, la revue automatique terminée et la preview disponible sur le commit courant. Le CTO lit ensuite le diff, teste le parcours concerné et choisit de merger ou de demander des corrections.

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.

1. 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.

2. 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.

3. 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.

4. 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.

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.