Plateforme
Backend : une fondation Supabase pour une livraison logicielle IA sérieuse
Authentification, une vraie base de données Postgres, stockage de fichiers et sécurité au niveau des lignes arrivent avec votre app — pas comme un projet séparé que vous devez câbler.
Le backend de Ciao est propulsé par Supabase : authentification, base de données Postgres, stockage de fichiers, sécurité au niveau des lignes et API générés aux côtés de votre application. Contrairement aux builders d'apps adossés à des feuilles de calcul, Ciao donne à chaque projet une vraie base de données relationnelle avec des règles d'accès appliquées à la base de données elle-même — une infrastructure standard que vos ingénieurs peuvent inspecter et interroger, et que vous possédez avec le reste du code.
Publié 2026-07-03 · Dernière mise à jour 2026-07-03
Les vraies apps ont besoin d'une vraie couche de données
Chaque application sérieuse est une base de données portant une interface utilisateur. La couche de données est aussi là où les builders d'apps coupent généralement les coins ronds : des feuilles de calcul comme stockage, une connexion greffée, des permissions comme un espoir. Ça marche dans la démo — puis une deuxième équipe, de vrais clients ou un auditeur se présente.
Ciao donne à chaque application un backend propulsé par Supabase : authentification, base de données Postgres, stockage de fichiers, sécurité au niveau des lignes et API — générés aux côtés de l'application et évoluant avec elle. C'est l'infrastructure que des ingénieurs choisiraient délibérément, arrivant sans la configuration. Et parce qu'elle arrive avec l'application, le modèle de données et l'interface ne dérivent jamais l'un de l'autre — l'un décrit l'autre.
Comment le backend s'assemble
Le backend est généré avec l'application et grandit via le même cycle.
1. Décrivez les données en langage clair
« Les clients ont des abonnements ; les factures appartiennent aux clients » devient un schéma relationnel dans Postgres, avec des types et relations appropriés.
2. L'authentification est câblée
Connexion, sessions et gestion des utilisateurs existent dès le départ, parce que l'auth est la fondation sur laquelle chaque règle d'accès se construit.
3. La sécurité au niveau des lignes applique qui voit quoi
Les règles d'accès vivent dans la base de données elle-même : les requêtes d'un utilisateur ne peuvent toucher que les lignes que la policy autorise, même si un bug se glisse dans le code applicatif.
4. Le stockage gère les fichiers
Téléversements, documents et images obtiennent un foyer avec les mêmes règles d'accès appliquées — pas un bucket public que quelqu'un comptait verrouiller plus tard.
5. Les API exposent les données
Des endpoints générés permettent à votre application — et à vos intégrations — de travailler avec les données de manière contrôlée et cohérente.
6. Le schéma évolue sous gouvernance
Les changements arrivent comme des migrations sur des branches, via revue et portes de QA, si bien que la couche de données grandit avec le produit au lieu de le combattre.
Pourquoi c'est important
La sécurité au niveau des lignes est le détail qui mérite qu'on s'y arrête. Les contrôles de permission au niveau applicatif échouent ouverts : une condition oubliée et les données fuient. La sécurité au niveau des lignes échoue fermée — la base de données refuse ce que la policy n'autorise pas. La couche Security de Ciao sonde ensuite ces frontières contre l'application en direct, si bien que « les permissions fonctionnent » est testé, pas supposé.
Et parce que c'est Supabase et Postgres — une infrastructure standard, largement utilisée — rien dans votre couche de données n'est propriétaire. Les ingénieurs peuvent l'interroger directement, et si vous exportez l'application, le schéma et le modèle de données partent avec vous. 100% propriété inclut le backend.
Le backend est aussi là où le développement assisté par IA a le plus besoin de discipline, parce que les données survivent aux fonctionnalités. Les écrans sont reconstruits ; les schémas s'accumulent. Générer la couche de données via des migrations gouvernées — revues, testées, enregistrées — signifie que la base de données cinq cents modifications plus tard est toujours un schéma que quelqu'un peut lire, pas un site archéologique avec une page de connexion.
Qui l'utilise
Une vraie couche de données change ce sur quoi chaque rôle peut compter.
- Non-ingénieurs — Ils obtiennent une couche de données correcte — vrai schéma, permissions appliquées — sans avoir besoin de savoir ce qu'est l'une ou l'autre.
- Ingénieurs — Du Postgres standard qu'ils peuvent inspecter et interroger, sans moteur de stockage propriétaire attendant de les surprendre à l'export.
- Agences — Chaque build client repose sur la même fondation fiable au lieu de ce que le projet de la semaine a improvisé.
- Équipes réglementées — Règles d'accès appliquées, frontières sondées et un audit trail — l'histoire de couche de données que la conformité demande réellement.
Notes sur la sécurité et la gouvernance
- ✓ La sécurité au niveau des lignes applique l'accès à la base de données, pas seulement dans l'UI.
- ✓ Les sondes de contrôle d'accès de Ciao Security exercent ces règles contre l'app en direct.
- ✓ Les changements de schéma livrent comme des migrations via branches, revue et portes de QA.
- ✓ Le contrôle d'accès basé sur les rôles régit qui peut modifier la couche de données.
- ✓ Le stockage de fichiers hérite des mêmes règles d'accès que les données auxquelles il appartient.
- ✓ Le code client n'est pas utilisé pour entraîner les modèles ; l'inférence s'exécute sous des contrats modèle à conservation zéro.
- ✓ Le schéma est du Postgres standard — exportable avec votre application à tout moment.
Ce que chaque backend Ciao inclut
Tout dans ce tableau est livré avec chaque projet — rien de tout cela n'est une mise à niveau.
| Capacité | Ce que vous obtenez |
|---|---|
| Authentification | Connexion, sessions et gestion des utilisateurs câblées dans l'app dès le départ |
| Base de données Postgres | Un vrai schéma relationnel généré à partir de descriptions en langage clair |
| Stockage de fichiers | Téléversements et documents avec les mêmes règles d'accès appliquées |
| Sécurité au niveau des lignes | Accès appliqué par la base de données elle-même, sondé contre l'app en direct |
| API | Endpoints générés pour votre application et ses intégrations |
Questions fréquentes
Le backend est-il verrouillé à Ciao ?
Non. Il est propulsé par Supabase, du Postgres standard, et exporter votre application inclut le schéma et le modèle de données. Il n'y a aucun moteur de stockage propriétaire entre vous et vos données.
Qu'est-ce que la sécurité au niveau des lignes en pratique ?
Des policies qui vivent dans la base de données et décident, ligne par ligne, ce que chaque utilisateur peut lire ou écrire. Si le code applicatif a un bug, la base de données refuse quand même les requêtes que la policy n'autorise pas — les permissions échouent fermées plutôt qu'ouvertes.
Nos ingénieurs peuvent-ils travailler directement avec la base de données ?
Oui — c'est du Postgres standard, donc ils peuvent l'inspecter et l'interroger avec les outils qu'ils utilisent déjà. Les changements de schéma passent toujours par des migrations gouvernées, si bien que l'accès direct ne devient pas un changement non documenté.
Pouvons-nous apporter des données existantes dans une app Ciao ?
Oui — décrivez la forme de ce que vous avez et le schéma est construit pour le recevoir, avec les imports gérés dans le cadre du build. Pour des migrations plus grandes ou plus sensibles, discutez-en d'abord avec l'équipe.
Comment le backend interagit-il avec les tests de sécurité ?
Les sondes de contrôle d'accès tentent des lectures et écritures cross-frontière contre l'application en direct — les policies de sécurité au niveau des lignes sont exercées, pas seulement revues. Les résultats alimentent le dashboard bon-à-publier.