Expertise Vercel / Supabase

Votre site peut faire partie de votre système métier.

Un catalogue qui se met à jour depuis le référentiel. Un formulaire qui rejoint le bon processus. Un back-office que l’équipe peut faire vivre. Nous relions ces pièces avec vous.

Quatre ans de construction et d’évolution d’outils au sein d’un groupe d’emploi et de formation : l’expérience de Julien Cyr, fondateur d’Ownward, nourrit ces cas anonymisés. Un même contexte métier, plusieurs produits complémentaires.

Le bon outil à chaque endroit

Un socle. Plusieurs possibilités. Données communes · Espace équipe · Site connecté

Airtable reste pratique pour les équipes qui structurent l’offre. Supabase fournit un modèle PostgreSQL, l’authentification et le stockage. Next.js sur Vercel construit l’expérience publique ou connectée autour de ces données.

Nous définissons les données maîtres, les champs diffusés et les responsabilités de chaque outil. Une copie destinée au web a un rôle clair ; elle ne devient pas un second référentiel à maintenir à la main.

Notre organisation du code · monorepo

Plusieurs applications. Un socle commun.

Un monorepo rassemble le code d’applications liées dans un même dépôt versionné. Site web, back-office et espace client peuvent partager leur design system et leurs contrats métier tout en restant des applications déployées séparément.

  • Site public
  • Back-office
  • Espace client
  • Hub d’applications

Packages partagés : marque · composants · types · accès aux données

Une cohérence qui se voit

Chez Ownward, la même palette, les polices Source Sans 3 et les composants de logo servent désormais les quatre espaces. Une évolution de marque a une source unique, puis chaque application est reconstruite et vérifiée.

Des évolutions faciles à suivre

Les workspaces pnpm relient les packages ; Turborepo coordonne les tâches dépendantes et met en cache les constructions éligibles. Changements liés, documentation et consignes pour les agents restent révisables ensemble.

Chaque application garde ses limites

Chaque application a son projet Vercel et son déploiement. Partager du code ne donne aucun accès supplémentaire : sessions, permissions, secrets et isolation des clients demandent toujours des contrôles explicites.

Pertinent quand plusieurs produits évoluent ensemble. Nous définissons la responsabilité des packages et leur compatibilité avant de mutualiser. Un retour arrière du code ne restaure pas la base de données.

Les monorepos sur Vercel

Des données au produit

Un site qui travaille avec le reste de vos outils.

Explorez le catalogue connecté, la collecte de demandes et la publication sur plusieurs sites.

Référentiel & publication

Du référentiel Airtable à un catalogue web vivant.

Au départ…

La communication doit publier un catalogue consultable et des pages programme à partir du référentiel métier, tout en gardant la maîtrise de ce que les visiteurs voient.

Ce que nous avons construit

Une copie de publication Supabase et un site Next.js sur Vercel. Les champs sources sélectionnés alimentent le catalogue ; les statuts éditoriaux, médias conservés et requêtes publiques définissent le parcours visiteur.

Technologies et documentations officielles

Une donnée, plusieurs usages
  1. Airtable

    Maintenir

    Modèle métier et relations

  2. Supabase

    Préparer la diffusion

    Champs choisis, statuts et médias

  3. Vercel

    Servir le site

    Next.js lit le catalogue publiable

Le flux documenté utilise une synchronisation dédiée. Zapier peut coordonner d’autres événements, mais ne remplace pas ce moteur dans ce cas.

Entrez dans l’outil

Écran 1 sur 2

2. Explorer le catalogue public

2. Explorer le catalogue public

Le site propose recherche et filtres à partir du référentiel synchronisé.

Ce que nous voulons changer

Tenir l’offre publique à jour tout en donnant à la communication une décision explicite de publication.

Comment c’est construitModèle de données, code, contrôles et autonomie des équipes

Parcours utilisateur

  1. 01

    Synchroniser les champs sources sélectionnés dans la copie de publication.

  2. 02

    Relire le contenu éditorial et approuver la publication.

  3. 03

    Servir le catalogue consultable et les pages programme liées.

Structure des données et des échanges

Entité / tableChamps clésRelations
Catalogue webairtable_id · statut · slugCopie de diffusion Supabase
Versions & synchronisationsÉtat · journal · versionHistorique de diffusion

Implémentation technique

  • Les champs sont remappés explicitement ; les enregistrements sont mis à jour par airtable_id stable.
  • Les visuels nécessaires au site sont copiés dans Storage, plutôt que de dépendre d’URL de pièces jointes temporaires.
  • Les nouveaux contenus arrivent en brouillon. Les disparitions sont marquées, avec un contrôle sur les variations importantes du catalogue.

Décision d’ingénierie

Limiter les écritures et préserver les décisions de publication

Adapté de l’upsert par lots et du mapping des champs pilotés par Airtable. Les identifiants source retrouvent les lignes existantes ; les champs éditoriaux de publication sont omis. Une erreur arrête les lots suivants et remonte au rapport. Les lots précédents restent écrits : une reprise peut reconverger, sans transaction globale du catalogue.

TypeScriptcatalogue-upsert.ts29 lignes
import type { SupabaseClient } from "@supabase/supabase-js";type Programme = {  sourceId: string; name: string; slug: string;};export async function syncProgrammes(db: SupabaseClient, source: Programme[]) {  // Only source-owned fields belong in this mapping.  // is_published, editorial content and SEO overrides stay out.  const rows = source.map(row => ({    airtable_id: row.sourceId,    name: row.name,    slug: row.slug,  }));  let written = 0;  for (let offset = 0; offset < rows.length; offset += 500) {    const chunk = rows.slice(offset, offset + 500);    const { error, count } = await db.from("programmes").upsert(chunk, {      onConflict: "airtable_id", count: "exact",    });    if (error) {      throw new Error(`Catalogue sync stopped after ${written} rows`);    }    written += count ?? chunk.length;  }  return { written };}// Database prerequisites: unique airtable_id, new rows default to draft.// Validate slugs and resolve collisions before this writer runs.

Extrait adapté de l’implémentation

Limiter les écritures et préserver les décisions de publication

Contrôles et limites

  • Le navigateur ne reçoit pas de jeton Airtable ni de clé Supabase privilégiée.
  • Les champs internes et données de personnel ne font pas partie du catalogue public.
  • Une synchronisation n’est pas une publication : les droits, statuts et filtres de diffusion ont leur propre rôle.

Qui peut contribuer

  • Métier : maintenir les formations, campus et liens Airtable.
  • Communication : enrichir et valider la publication dans le back-office web.
  • Développeurs : faire évoluer les mappings, contrôles et composants versionnés.

Ce qui documente ce cas

Source de synchronisation et modèle de publication examinés ; catalogue public et fiche formation ouverts. Les captures montrent le vrai parcours, avec les marques masquées.

Avec Ownward

Construit ensemble. À vous de le faire grandir.

Vos équipes doivent pouvoir gérer les évolutions du quotidien. Et savoir sur qui compter lorsqu’un sujet demande une expertise technique plus poussée.

  1. 01

    Partir du travail réel

    Nous définissons le besoin, les responsabilités de chaque outil et une première version vérifiable, puis construisons le parcours avec les équipes.

  2. 02

    Apprendre sur ses propres outils

    Vos équipes apprennent sur le produit livré : configuration, suivi, diagnostic et évolutions courantes, avec la documentation et le dépôt à leur disposition.

  3. 03

    Aller plus loin, bien accompagné

    Citizen developers, développeurs et collègues qui codent avec Claude contribuent au même modèle documenté. Nous accompagnons les intégrations complexes, les revues de code et les escalades techniques dans la durée.

Le soin apporté à la livraison

Un outil livré avec tout ce qu’il faut pour le prendre en main.

Notre standard de livraison Ownward : l’aide reste disponible dans le produit, le savoir reste avec le code et les agents disposent du contexte pour contribuer.

  • Un assistant de prise en main toujours accessible

    Un parcours guidé pour comprendre les rôles, configurer les éléments essentiels et réussir la première action. Il reste accessible depuis l’aide, y compris pour accueillir de nouveaux collègues.

  • La documentation dans le dépôt livré

    Démarrage, modèle de données, configuration, intégrations, tests, publication et retour arrière : les explications évoluent avec la version du produit. Les secrets restent hors du dépôt.

  • Des consignes pour les agents codeurs

    AGENTS.md et, si utile, CLAUDE.md précisent l’architecture, les conventions, les commandes de vérification et les règles de modification. Un agent prolonge le modèle partagé ; l’équipe garde la revue et la décision de diffusion.

Voir un guide de prise en main dans une interface réelle
Déploiement, accès et évolution du produit

Nous utilisons les previews pour relire une évolution avant sa diffusion. Les règles PostgreSQL et les autorisations de l’application portent les accès ; les clés privilégiées restent côté serveur. Les vérifications doivent couvrir les accès refusés autant que les accès autorisés.

Revenir à un déploiement Vercel précédent ne restaure pas la base de données. Nous prévoyons séparément la compatibilité des migrations, les sauvegardes et la reprise.

Quelle partie de votre travail pourrait être plus simple ?

Un processus, un point de friction, une idée : partons de là.

Parlons de votre projet