Alternatives / XANO

Xano vs Logiciel Sur-Mesure : Quand la Function Stack devient un plafond de verre

Xano a séduit des milliers d'équipes avec sa promesse de backend no-code puissant : base de données PostgreSQL, API générées automatiquement, logique visuelle sans écrire de code. Mais quand votre application devient critique, la Function Stack propriétaire montre ses limites : logique non exportable, tests automatisés impossibles, facture Pro à $224/mois. Si votre projet a dépassé le stade du MVP, voici ce qu'il faut anticiper.

4,7

| Voir nos avis clients

Interface Xano : vue Function Stack et éditeur de logique métier visuelle

SOYONS HONNÊTES

Ce que Xano fait vraiment bien

Avant de parler limites, reconnaissons pourquoi Xano vous a séduit à la base tout comme des millions d'utilisateurs.

Backend no-code complet: Base de données PostgreSQL, API REST générées automatiquement, authentification et stockage inclus : Xano centralise tout le backend sans écrire de code. Idéal pour lancer un MVP en quelques jours.
Function Stack visuelle: Construisez des logiques métier complexes via des blocs visuels enchaînables. Conditions, boucles, appels API, transformations de données : tout est configurable sans code.
API-first par design: Chaque table génère automatiquement des endpoints REST documentés. Connectez Xano à n'importe quel frontend (Bubble, Webflow, FlutterFlow) ou outil tiers sans configuration manuelle.
Scalabilité serverless: L'infrastructure de Xano s'adapte automatiquement à la charge. Pas de serveur à provisionner, pas de configuration d'autoscaling à gérer en cas de pic de trafic.
Intégrations natives: Zapier, Make, Stripe, Twilio et des centaines d'autres services sont disponibles en natif dans la Function Stack, sans avoir besoin d'écrire une ligne de code d'intégration.

Ces points forts restent valables. La question n'est pas "Xano est-il bon ?" mais "Xano est-il fait pour ce que vous en faites aujourd'hui ?"

LE PLAFOND DE VERRE

Pourquoi Xano finit par freiner votre croissance

Ces limites ne sont pas des bugs. Xano est un outil généraliste conçu pour s'adapter à toutes les situations, avec de nombreuses options de paramétrage.

C'est précisément ce qui en fait sa valeur, mais aussi ce qui vous transfère la charge de concevoir et de maintenir votre propre système dans le temps.

Logique métier enfermée dans des blocs non exportables

La Function Stack de Xano est un langage visuel propriétaire. Toute la logique que vous construisez (conditions, calculs, appels API, transformations) est stockée dans le format interne de Xano. Il n'existe pas d'export vers du code Python, JavaScript ou PHP. Si vous décidez de quitter Xano ou si la plateforme disparaît, toute votre logique métier doit être réécrite de zéro. Le vendor lock-in ne porte pas sur les données (PostgreSQL exportable), mais sur la totalité de votre logique applicative.

Tests limités à l'interface, sans intégration dans un pipeline CI/CD

Xano propose des Unit Tests et des Test Suites depuis son interface : assertions sur les réponses, mocking des fonctions, mesure de couverture. Mais ces tests vivent dans Xano, pas dans votre dépôt Git. Il n'existe pas de commande pour les déclencher depuis une CI : si une modification casse un comportement existant, rien ne l'intercepte automatiquement avant le déploiement en production. Dans un logiciel développé en code, les tests s'exécutent à chaque pull request et bloquent le merge en cas de régression. Ce filet de sécurité automatique n'existe pas sur Xano.

Coût élevé dès que l'équipe grandit

Le plan Starter à 25$/mois est limité à un espace de travail avec des contraintes sur les instances. Dès que vous avez besoin d'environnements séparés (dev, staging, production), de gestion des rôles ou d'une infrastructure dédiée, il faut passer au plan Pro à 224$/mois. Sur 3 ans, c'est 8 064$, sans posséder ni le code ni l'infrastructure. Un logiciel sur mesure est un investissement unique dont vous êtes propriétaire.

Backend uniquement : dépendance à un deuxième outil pour le frontend

Xano gère exclusivement la partie backend. Pour construire une interface utilisateur, vous devez utiliser un outil complémentaire (Bubble, Webflow, FlutterFlow, WeWeb). Chaque outil ajoute sa propre courbe d'apprentissage, son propre abonnement et son propre risque de vendor lock-in. Un logiciel sur mesure intègre backend et frontend dans un seul périmètre technique maîtrisé.

L'ALTERNATIVE SMARTBOOSTER

Un logiciel métier qui modélise votre réalité sans compromis

Remplacez Xano par un logiciel sur mesure Symfony/Vue.js qui vous offre une vraie base relationnelle SQL, des droits d'accès granulaires et une logique métier illimitée, sans sacrifier l'ergonomie que vos équipes apprécient.

Base de données relationnelle complète: Clients, commandes, lignes, produits reliés avec des jointures SQL, sans limite de volume ni de structure.
RBAC granulaire: Droits par rôle, par équipe, par ligne de données : conformité RGPD native et confidentialité interne garantie.
Automatisations métier réelles: Calculs, règles conditionnelles complexes, déclencheurs horaires, intégrations API tierces sans limite.
Hébergement Clever Cloud France: Souveraineté totale sur vos données, SLA garanti, données hors CLOUD Act américain.
Interface sur mesure: UX conçue pour vos processus spécifiques, pas pour un usage générique : adoption rapide par vos équipes.

Interface exemple d'un logiciel développé en Symfony Vue.js par SmartBooster

LA QUESTION IMPORTANTE

Avez-vous réellement besoin de quitter totalement Xano ?

Chez SmartBooster, nous conseillons nos clients dans leur intérêt et ne reconstruisons pas ce qui fonctionne déjà. Si Xano est en place dans votre entreprise, il reste certainement pertinent pour certains usages.

Nous commençons toujours par une cartographie de l'existant pour valider ce qui doit être migré et ce qui peut rester dans Xano. Et souvent, la meilleure solution consiste à faire communiquer intelligemment les outils entre eux via des API.

Connecter Xano à vos outils via API

COMPARATIF

Xano vs Logiciel Sur-Mesure

Une comparaison objective pour vous aider à décider.

Critère	Xano	Sur-mesure SmartBooster
Propriété des données	Chez Xano Inc. (USA)	100% propriétaire, hébergé en France
Coût sur 3 ans (plan Pro)	~8 100€ ($224/mois × 36 mois)	Investissement unique, pas d'abonnement récurrent
Logique métier	Function Stack visuelle propriétaire, non exportable	Services Symfony versionnés, documentés, portables
Tests automatisés	Unit Tests et Test Suites dans l'interface, sans CI/CD ni exécution automatique au déploiement	Chaque règle métier couverte et validée à chaque déploiement
Frontend	Backend uniquement, outil tiers obligatoire pour l'UI	Backend et frontend intégrés (Symfony + Vue.js)
Portabilité	Données exportables, logique non exportable	Code source livré, hébergement transférable
Vendor lock-in	Total sur la logique applicative, partiel sur les données	Aucun : vous possédez le code et l'infrastructure

Comparaison technique : Xano vs Logiciel Sur-Mesure

Database, APIs, logique métier, automatisation, tests et monitoring : comparaison point par point entre Xano et un développement sur mesure Symfony.

Database : modélisation et migrations

Xano s'appuie sur PostgreSQL en interne et offre une expérience visuelle de modélisation depuis l'onglet Database. Les données sont exportables en CSV ou JSON, mais le schéma et les relations vivent dans l'interface et doivent être rejoués manuellement à la sortie. Sur un projet Symfony, le schéma est généré depuis des entités PHP et chaque évolution est une migration Doctrine versionnée.

Modélisation des tables

L'objectif est de définir tables, colonnes, types et relations d'une manière qui reste lisible dans le code, traçable dans Git, et reproductible à l'identique sur n'importe quel environnement.

Xano

Les tables se créent dans l'onglet Database via une interface visuelle. Xano propose des types riches (text, decimal, timestamp, json, vector, enum) et des relations via Table Reference. Le schéma vit dans l'interface : pour le retrouver dans le code, il faut interroger la Metadata API ou lire un export XanoScript. Il n'existe pas de description du schéma directement versionnée dans un dépôt Git.

Code XanoScript de la table

php

table project {
  auth = false

  schema {
    int id
    timestamp created_at?=now {
      visibility = "private"
    }

    // The name of the project.
    text name? filters=trim

    // Reference to the team that owns this project.
    int team? {
      table = "team"
    }
  }

  index = [
    {type: "primary", field: [{name: "id"}]}
    {type: "btree", field: [{name: "created_at", op: "desc"}]}
  ]
}

Code sur mesure

Le schéma est défini dans des entités Doctrine en PHP : chaque table correspond à une classe, chaque colonne à une propriété annotée. Les relations entre entités sont déclarées explicitement (OneToMany, ManyToOne, ManyToMany). MakerBundle génère les entités depuis la ligne de commande, et Doctrine ORM produit ensuite le SQL adapté à la base cible. Toute l'information vit dans le code source.

Entité Doctrine équivalente à une table Xano

Exemple d'intéraction avec l'utilitaire MakerBundle pour faciliter la création d'entité :

Exemple de génération d'entité avec le MakerBundle

Code PHP de l'Entité Doctrine équivalente :

php

#[ORMEntity(repositoryClass: ProjectRepository::class)]
class Project
{
  #[ORMId]
  #[ORMGeneratedValue]
  #[ORMColumn]
  private ?int $id = null;

  #[ORMColumn(type: Types::TEXT)]
  private ?string $name = null;

  #[ORMManyToOne]
  private ?Team $team = null;

  #[ORMColumn]
  private ?DateTimeImmutable $createdAt = null;

PHPStorm notre IDE de code nous permet aussi de visualiser le schéma d'une base de donnée :

PHPStorm exemple de diagram de base de données auto généré

Export et portabilité du schéma

L'objectif est de pouvoir reproduire l'intégralité de la structure (tables, relations, contraintes, index) sur un autre système sans avoir à inspecter manuellement l'interface, et de pouvoir revenir à un état antérieur si une migration introduit un problème.

Xano

Les données s'exportent en CSV ou JSON, table par table. Le schéma, lui, est décrit dans l'interface Xano ou en XanoScript. Migrer vers une base SQL standard impose de relire chaque table dans l'UI, de retranscrire les relations Table Reference en clés étrangères, et de recréer les contraintes à la main. La portabilité des données est réelle, celle du schéma demande un travail d'analyse.

Endpoint Metadata API d'export du schéma de tables et de la configuration de branche

bash

POST /workspace/{workspace_id}/export-schema
Authorization: Bearer {access_token}
Content-Type: application/json

{
"branch": "",
"password": ""
}

Écran Xano d'export des données d'une table en CSV

Attention, malgré que Xano repose sur PostgreSQL, il n'est pas possible de faire un dump complet du workspace contrairement à Supabase.

Code sur mesure

Le schéma est généré par Doctrine à partir des entités, et chaque évolution produit une migration PHP horodatée avec ses méthodes up() et down(). Les migrations sont rejouées dans l'ordre sur chaque environnement et exécutées en CI/CD à chaque déploiement. Un pg_dump produit un fichier SQL standard qu'un développeur peut rejouer sur n'importe quel PostgreSQL : pas de format propriétaire, pas de Metadata API à interroger.

Lancement des commandes doctrine pour générer des migrations

Migration Doctrine versionnée

php

final class Version20260512090934 extends AbstractMigration
{
  public function getDescription(): string
  {
      return 'Ajout de la table deal (opportunité)';
  }

  public function up(Schema $schema): void
  {
      $this->addSql('CREATE TABLE deal (id INT AUTO_INCREMENT NOT NULL, name LONGTEXT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8mb4 ENGINE = InnoDB');
      $this->addSql('DROP TABLE dummy');
  }

  public function down(Schema $schema): void
  {
      $this->addSql('CREATE TABLE dummy (id INT AUTO_INCREMENT NOT NULL, foo VARCHAR(255) CHARACTER SET utf8mb4 NOT NULL, bar VARCHAR(255) CHARACTER SET utf8mb4 NOT NULL , PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8mb4 ENGINE = InnoDB COMMENT = '' ');
      $this->addSql('DROP TABLE deal');
  }
}

APIs : endpoints, groupes et documentation

Xano organise les endpoints en API Groups et propose trois vues d'édition : Canvas View visuelle, Function Stack séquentielle et XanoScript textuel. Contrairement à Supabase qui se contente d'un explorateur par table sans contrat OpenAPI exploitable, Xano génère une documentation Swagger / OpenAPI complète par groupe, configurable en accès public, privé ou désactivé. Sur un projet Symfony, API Platform produit la même expérience depuis des entités Doctrine, le tout versionnable dans Git.

Construction des endpoints et organisation

L'objectif est de proposer des contrats d'API clairs, organisés par périmètre fonctionnel, et alignés sur les besoins du frontend (filtres, projections, pagination, formats de réponse).

Xano

Chaque endpoint Xano est composé de trois sections : Inputs, Logic (la Function Stack) et Response. Les API Groups les regroupent en dossiers organisationnels avec leur propre nom, description, tags et paramètres de documentation. Xano propose huit types d'endpoints prédéfinis : Custom Endpoint, External API request, CRUD Database Operations, Webhook, Authentication, Upload Content, HTML Page et XanoScript. Le nombre de versions conservées par endpoint dépend du plan : 0 sur Free, 10 sur Essential, 20 sur Pro, illimité sur Custom.

Interface endpoint Xano de configuration avec la vue Canvas

Configuration de l'endpoint avec la vue Stack

Interface endpoint Xano de configuration avec la vue Stack

XanoScript d'un endpoint GET

yaml

// List all projects
// Retrieve a list of all projects with optional pagination
query project verb=GET {
api_group = "Resources"

input {
  int page?=1 filters=min:1
  int per_page?=20 filters=min:1|max:100
}

stack {
  db.query project {
    sort = {created_at: "desc"}
    return = {
      type  : "list"
      paging: {page: $input.page, per_page: $input.per_page}
    }
  } as $projects
}

response = $projects
}

Code sur mesure

API Platform Symfony génère un contrat REST ou GraphQL à partir des entités Doctrine, avec OpenAPI auto-généré et négociation de format. Les contrôleurs sont du code PHP standard, revus en pull request, testés en CI, et alignés sur les besoins exacts du frontend. Versioning, pagination, filtres et projections sont configurables précisément par ressource, et le code reste portable d'un projet à l'autre.

Exposition d'une ressource via API Platform

php

#[ApiResource(
  operations: [
      new GetCollection(),
      new Get(),
      new Post(),
      new Patch(),
  ],
  normalizationContext: ['groups' => ['project:read']],
)]
#[ORM\Entity]
class Project
{
  #[ORM\Id, ORM\GeneratedValue, ORM\Column]
  #[Groups(['project:read'])]
  private ?int $id = null;

            #[ORM\Column(type: Types::TEXT)]
            #[Groups(['project:read'])]
            private string $name;
        }

Documentation Swagger / OpenAPI

L'objectif est d'offrir aux consommateurs de l'API (équipes frontend, partenaires, équipes mobile) une documentation interactive à jour, avec essai en direct et clarté sur les contrats de chaque endpoint.

Xano

Chaque API Group expose une documentation Swagger / OpenAPI auto-générée à partir des endpoints qu'il contient. À la création du groupe, on choisit l'un des trois modes : public sans authentification, privé avec token, ou désactivé. C'est un avantage net face à Supabase qui se limite à un explorateur par table sans contrat OpenAPI exploitable. La doc reste cependant servie depuis l'infrastructure Xano : pas de fichier openapi.yaml versionnable dans votre dépôt, pas de génération de clients TypeScript.

Code sur mesure

API Platform génère le fichier openapi.yaml et l'expose via une UI Swagger ou Redoc. Le fichier est consultable, téléchargeable, et peut être commité dans le dépôt pour servir de contrat de référence. La documentation reste cohérente avec le code car elle est dérivée des annotations PHP : aucune divergence possible entre la doc publiée et le comportement réel des endpoints.

Doc OpenAPI auto généré par ApiPlatform sur les endpoints

Functions et Middleware : logique réutilisable et transverse

Xano sépare les Custom Functions (logique réutilisable interne, non exposée publiquement) du Middleware (logique transverse pré ou post-exécution). Les deux vivent dans la Function Stack visuelle et peuvent être attachés au workspace entier, à un API Group ou à un endpoint unique. Sur un projet Symfony, les Services et les EventSubscribers couvrent les mêmes besoins avec injection de dépendances, tests automatisés et code versionné.

Custom Functions : la logique réutilisable

L'objectif est d'extraire une règle métier utilisée plusieurs fois (création d'utilisateur, calcul de tarif, génération de référence) pour qu'elle soit définie à un seul endroit, lisible et testable.

Xano

Une Custom Function partage la structure d'un endpoint (Inputs, Function Stack, Response) mais n'est pas appelable de l'extérieur : c'est une brique interne. Elle se crée dans le menu Functions, peut être taggée et organisée en dossiers, puis insérée dans n'importe quelle Function Stack via une recherche. On peut aussi convertir un stack existant ou des étapes spécifiques en Custom Function depuis le menu trois points, ce qui simplifie le refactoring. Le bloc security.create_auth_token y est typiquement utilisé pour l'authentification.

XanoScript : Custom Function de création d'utilisateur avec contrôle d'unicité

yaml

stack {
  db.get user {
    field_name = "email"
    field_value = $input.email
  } as $user

  precondition ($user == null) {
    error_type = "accessdenied"
    error = "This account is already in use."
  }

  db.add user {
    data = {
      created_at: "now"
      name      : $input.name
      email     : $input.email
      password  : $input.password
    }
  } as $user

  security.create_auth_token {
    dbtable = "user"
    expiration = 86400
    id = $user.id
  } as $authToken
}

Code sur mesure

La logique réutilisable est exprimée en Services Symfony : des classes PHP injectables, organisées par domaine fonctionnel et résolues automatiquement par le container. Chaque service est testable unitairement avec PHPUnit, peut composer d'autres services via injection de dépendances, et hérite de l'autoconfiguration de Symfony. Aucun runtime propriétaire, aucun export à demander pour reprendre le code.

Exemple d'arborescence des services dans un projet Backoffice sur mesure et exemple de UserManager :

Middleware : logique transverse pré et post-exécution

L'objectif est d'appliquer une règle commune à plusieurs endpoints (rate limiting, audit, normalisation des inputs, ajout d'un header de réponse) sans dupliquer cette logique dans chaque Function Stack.

Xano

Un Middleware Xano s'attache au workspace entier, à un API Group ou à un endpoint unique. Deux façons de l'implémenter : Pre-middleware (s'exécute avant la validation des inputs, sans connaissance des contraintes) et Post-middleware (s'exécute après la Function Stack, avec possibilité de remplacer ou fusionner la réponse). Cette menu est disponible uniquement à partir du plan Essential avec 10 middleware puis illimitées dans les plan supérieur.

Code sur mesure

La logique transverse passe par les EventSubscribers Symfony, branchés sur les événements du Kernel HTTP (kernel.request, kernel.controller, kernel.response, kernel.exception). Un même subscriber peut s'appliquer globalement, par contrôleur ou par attribut de méthode. Le code est testable, versionné dans Git, et le Symfony Profiler montre la chaîne complète des subscribers déclenchés sur chaque requête. Pas de limite sur le nombre de subscribers ni sur leur portée.

EventSubscriber Symfony équivalent à un Post-middleware d'audit

php

final class AuditResponseSubscriber implements EventSubscriberInterface
{
  public function __construct(private AuditLogger $audit) {}

  public static function getSubscribedEvents(): array
  {
      return [KernelEvents::RESPONSE => 'onResponse'];
  }

  public function onResponse(ResponseEvent $event): void
  {
      if (!$event->isMainRequest()) {
          return;
      }
      $this->audit->log(
          $event->getRequest()->getPathInfo(),
          $event->getResponse()->getStatusCode(),
      );
  }
}

Tasks et Triggers : automatisation planifiée et événementielle

Xano regroupe l'automatisation en deux concepts : Background Tasks pour les jobs planifiés (cron) et Triggers pour les workflows déclenchés par un événement (changement en base, message Realtime, appel d'agent IA, fusion de branche). Sur un projet Symfony, les Console Commands orchestrées par cron ou systemd, Symfony Messenger et les Doctrine lifecycle events couvrent les mêmes besoins.

Background Tasks : les jobs planifiés

L'objectif est de déclencher automatiquement des traitements récurrents (envoi de rapports, nettoyage de données, synchronisations périodiques) sans dépendre d'un déclencheur externe.

Xano

Un Background Task Xano est composé d'une Function Stack et d'un Schedule, sans inputs ni response. Une fois sauvegardé, il faut cliquer sur Enable Task avant publication. Si une nouvelle exécution est planifiée alors que la précédente n'est pas terminée, l'exécution suivante est ignorée pour éviter les chevauchements. Les Background Tasks sont disponibles à partir du plan Essential ; les schedules sub-minute (toutes les 30 secondes par exemple) nécessitent le plan Pro.

Écran de Xano de configuration des dates et fréquence des tâches (Task / Cron) :

Écran Xano de configuration de la périodicité des tâches (Cron)

Code sur mesure

Une tâche planifiée est une Symfony Console Command déclenchée par cron système, systemd timer ou Messenger Scheduler. La commande est une classe PHP versionnée dans Git, testable unitairement et tracée dans les logs applicatifs. La planification est elle-même versionnée (fichier crontab dans le dépôt ou attribut PHP), et l'ajout d'un job passe par une pull request comme n'importe quelle évolution du logiciel.

Exemple de crontab serveur :

bash

# Génération des factures le 1er de chaque mois à 00h00
0 0 1 * * php /var/www/app/bin/console app:generate_invoices >> /var/log/app/generate_invoices.log 2>&1

# Envoi des emails de relance chaque jour à 08h00
0 8 * * * php /var/www/app/bin/console app:send_reminder_emails >> /var/log/app/send_reminder_emails.log 2>&1

# Nettoyage de la base chaque dimanche à 02h00
0 2 * * 0 php /var/www/app/bin/console app:cleanup_database >> /var/log/app/cleanup_database.log 2>&1

Triggers : les workflows événementiels

L'objectif est de réagir automatiquement à un événement (insertion en base, message Realtime, fusion de branche) sans avoir à appeler manuellement une fonction depuis chaque endpoint concerné.

Xano

Xano propose cinq familles de Triggers : Database Triggers (insert / update / delete / truncate avec filtres et inputs prédéfinis new, old, action, data source), Realtime Triggers (messages de canal, connexion client), Workspace Triggers (création de branche, fusion, passage en live), MCP Server Triggers (Client Connect) et AI Agent Triggers (modification du toolset à chaque appel d'agent). Cette puissance a un revers : la logique d'une fonctionnalité peut être éclatée entre une Function Stack, un Database Trigger en cascade et un AI Agent Trigger, ce qui complique le débogage.

Formulaire Xano d'ajout d'un Trigger de type base de données :

Code sur mesure

La réaction à un événement passe par trois mécanismes complémentaires, choisis selon la nature de l'événement : Doctrine Lifecycle Events pour réagir à un changement d'entité (prePersist, postUpdate...), Symfony Messenger pour traiter un événement de manière asynchrone et fiable (avec retry, DLQ et workers), et EventDispatcher pour les événements applicatifs internes. Chaque listener est un service testable, et le Symfony Profiler retrace la chaîne complète des événements déclenchés sur une requête.

Doctrine listener réagissant à la création d'un Project

php

#[AsEntityListener(event: Events::postPersist, entity: Project::class)]
final class NotifyOnProjectCreated
{
  public function __construct(private MessageBusInterface $bus) {}

  public function postPersist(Project $project, PostPersistEventArgs $args): void
  {
      $this->bus->dispatch(new SendProjectCreatedEmail($project->getId()));
  }
}

Test & Deploy : tests automatisés et débogage

Xano propose Unit Tests et Test Suites depuis l'onglet Test & Deploy : assertions, mocking et mesure de couverture par fonctionnalité. Mais ces tests vivent dans l'interface et ne s'intègrent pas dans un pipeline CI/CD. Sur un projet Symfony, PHPUnit ou Pest tournent à chaque pull request en CI et bloquent le merge en cas de régression.

Tests automatisés et débogage

L'objectif est de détecter automatiquement les régressions à chaque modification, et de pouvoir tracer un bug jusqu'à sa source sans avoir à rejouer manuellement chaque scénario utilisateur dans une interface graphique.

Xano

Xano propose des Unit Tests et des Test Suites depuis l'onglet Test & Deploy : assertions sur les réponses, mocking des fonctions, mesure de couverture par fonctionnalité, debugger intégré qui rejoue la Function Stack pas à pas. Les Test Suites travaillent sur une copie de la base pour ne pas impacter les données réelles. L'usage illimité nécessite le plan Pro à 224$/mois. Mais les tests vivent dans l'interface Xano, pas dans votre dépôt Git : pas de versioning des cas de test avec le code, pas de déclenchement automatique en CI, pas de commande qui bloque un déploiement en cas de régression. Sur un projet avec des dizaines de workflows, cette absence de pipeline de test automatisé est un risque opérationnel réel.

Écran Xano de visualisation des tests unitaires par typologie (API, Fonctions) :

Écran Xano de visualisation des Workflow tests :

Code sur mesure

Chaque règle métier est couverte par PHPUnit ou Pest : tests unitaires sur les services, tests fonctionnels sur les contrôleurs, fixtures de données versionnées dans Git. Le rapport de couverture est généré à chaque pull request, et la CI bloque le merge si un test casse. Le Symfony Profiler trace chaque requête HTTP avec son SQL, ses services appelés et ses exceptions, sans avoir à rejouer manuellement le scénario.

Exemple de test et couverture de code analysé sur nos projets avec PHPUnit qui tourne sur nos CI Gitlab.

Example PHPUnit de coverage et validation de services

Écran Symfony Profiler pour analyser les requêtes effectué par Doctrine

Interface Profiler Symfony des requêtes Doctrine

Monitor : performance, audit et conformité

Xano centralise l'observabilité dans un onglet Monitor : Performance Insights pour les temps d'exécution, Audit Logs pour la traçabilité des actions. La rétention des logs et l'accès au Performance insights dépendent du plan. Sur un projet Symfony, ces capacités sont reconstituées avec le Symfony Profiler en dev et des outils standards (Sentry, Log Clever Cloud) en production, sans paywall ni rétention imposée par un éditeur.

Performance Insights et Audit Logs

L'objectif est de comprendre les goulets d'étranglement du backend et de garder une trace fiable de qui a fait quoi sur le système, avec une rétention adaptée aux contraintes réglementaires.

Xano

Performance Insights expose le temps moyen d'exécution des Lambda functions, les requêtes les plus gourmandes et la fréquence d'exécution des opérations sur 24h ou 30 jours. Trois métriques sont consultables : Average, Count, Total Time. La Stack View montre la durée d'exécution de chaque statement d'une Function Stack. Les Audit Logs tracent les actions sur le workspace, mais leur rétention dépend du plan : 30 jours sur Free et 1 an sur plan supérieur.

Code sur mesure

Le Symfony Profiler donne en développement le détail de chaque requête HTTP : SQL exécuté avec timing, services appelés, mémoire consommée, exceptions, événements déclenchés. En production, Sentry capte erreurs et performances applicatives. La rétention est décidée par vous, pas par un éditeur, et n'est limitée que par votre stockage.

Exemple d'écran sur mesure de monitoring API :

Avoir un écran sur mesure permet d'aller plus loin dans le monitoring et permettant par exemple de relancer directement les appels API.

Monitoring applicatif des erreurs ou requête lente dans Sentry :

Host Files : hébergement frontend et stockage

Xano regroupe sous Host Files trois types d'assets : Static Hosts pour héberger un frontend statique aux côtés du backend, Public Files pour les contenus à URL ouverte et Private Files pour les fichiers à accès contrôlé. Sur un projet Symfony, l'hébergement frontend, le CDN et la gestion des fichiers passent par des composants standards entièrement maîtrisés.

Hébergement frontend et gestion des fichiers

L'objectif est de servir le frontend et les fichiers métier (documents, images, exports PDF) avec un contrôle d'accès aligné sur les règles du logiciel, sans multiplier les contrats d'hébergement ni se lier à un fournisseur unique.

Xano

Host Files regroupe trois types d'assets. Static Hosts déploie un frontend pré-buildé ou un projet avec package.json via la CLI Xano, mais ancre le déploiement dans l'infrastructure Xano. Public Files expose les fichiers en URL statique sans contrôle d'accès. Private Files contrôle l'accès via une Function Stack, avec une limite de stockage selon le plan (1 GB sur Free, 100 GB sur Essential) et un passage à S3 via Cloud Services si besoin.

Déploiement d'un frontend via la CLI Xano et stockage d'un fichier dans une Function Stack

bash

# Déploiement du frontend
npm run build
zip -r build.zip ./dist
xano static_host build create my-site -f ./build.zip -n "v1.0.0"

yaml

# Stockage d'un fichier dans une Function Stack
file_storage.create {
file = $input.uploaded_file
bucket = "invoices"
} as $stored_file

db.edit invoice {
field_name = "id"
field_value = $invoice.id
data = { pdf_file: $stored_file }
}

Code sur mesure

Le stockage des fichiers métier passe par Flysystem, l'abstraction Symfony qui s'adapte à n'importe quel fournisseur (S3, Scaleway, OVH, Clever Cloud Cellar) sans réécriture du code applicatif. Le contrôle d'accès est géré via les voters Symfony : un fichier privé transite par un endpoint qui vérifie le droit avant de streamer le contenu, jamais exposé en URL directe.

Exemple de configuration Flysystem mixant fournisseur S3 et local storage via FSBucket

yaml

flysystem:
storages:
  local.calculation_file:
      adapter: 'local'
      directory_visibility: public
      options:
          directory: '%app.public_dir%%app.files.calculation_file_prefix%'
  aws.entity_file:
      adapter: 'aws'
      options:
          client: 'AwsS3S3Client'
          bucket: '%env(CELLAR_ADDON_BUCKET_FILES_NAME)%'
          prefix: '%app.files.entity_file_prefix%'

Exemples d'utilisation

Ce que nous pouvons construire !

En fonction de vos priorités, nous pouvons utiliser des composants préexistants pour gagner du temps sur les parties non-essentielles et aller jusqu'au 100% sur mesure pour les parties critiques de votre projet.

Interface de gestion & Administration

Pilotez vos données internes avec une interface d'administration sécurisée, conçue pour centraliser vos processus métier complexes.

Découvrir

CRM & Gestion Commerciale

Centralisez vos prospects, automatisez vos tunnels de vente et boostez votre conversion avec un CRM sur mesure adapté à votre cycle de vente.

Découvrir

Création de Plateforme SaaS

Lancez votre produit logiciel sur une base scalable : gestion multi-tenant, abonnements, RBAC et infrastructure haute disponibilité.

Découvrir

Reporting & Business Intelligence

Visualisez vos KPIs en temps réel avec des tableaux de bord interactifs : génération de rapports PDF, alertes et suivi d'objectifs.

Découvrir

Gestion de Tâches & Suivi d'Activité

Planifiez, assignez et suivez les tâches de vos équipes avec un outil adapté à vos processus : kanban, checklists, workflows et alertes.

Découvrir

Logiciel de Diagnostic & Audit

Automatisez vos expertises : questionnaires intelligents, calcul de scores métier et génération instantanée de rapports PDF.

Voir plus d'exemples

RENDEZ-VOUS DÉCOUVERTE GRATUIT

Votre usage de Xano vous freine-t-il ?

En 30 minutes d'échange, nous analysons votre situation et vous disons honnêtement si un logiciel sur mesure vous apporterait une valeur réelle.

Appel de 30 min → Analyse gratuite → Proposition sous 5 jours

Prendre rendez-vous

LA MIGRATION

Migrer depuis Xano sans perdre vos données ni votre logique

Xano permet d'exporter vos données en CSV ou JSON. Nous analysons la structure de vos tables, remappons les relations et migrons l'historique vers une base SQL propre. La Function Stack est analysée bloc par bloc et réécrite en services applicatifs couverts par des tests automatisés. Votre équipe continue à travailler sur Xano pendant le développement.

Étape 1 : Analyse

Cartographie de ce qui existe dans Xano

Avant de migrer quoi que ce soit, nous analysons l'ensemble de votre usage de Xano : bases de données, relations entre entités, automatisations en place, volumes de données.

Nous identifions précisément ce qui doit migrer vers le logiciel sur mesure et ce qui peut rester dans Xano. Cet état des lieux dessine une vision claire de votre façon de travailler : ce que nous devons conserver, améliorer, supprimer et créer dans votre nouveau logiciel.

Pour comprendre comment vos données sont organisées dans Xano avant la migration : documentation officielle Xano

Audit des bases et relations

Inventaire de toutes vos bases, propriétés, relations et vues dans Xano pour établir une carte complète de vos données.

Décision sur ce qui migre

Concertation sur ce qui passe dans le logiciel et ce qui reste dans Xano, pour ne reconstruire que ce qui apporte une vraie valeur.

Plan de migration validé

Document structuré avec priorités, format cible et estimation. Vous validez avant de démarrer.

Étape 2 : Migration

Import contrôlé de votre historique

Xano propose un export de vos données. Nous analysons la structure exportée, reconstituons les relations entre entités et importons l'historique dans la nouvelle base SQL.

Chaque import est contrôlé : les données mal formées sont signalées avant injection, pas après. Votre historique arrive sans perte ni approximation. Selon votre contexte, nous pouvons réaliser l'import directement ou vous construire des écrans d'import sur mesure : vous gardez ainsi la main pour trier, corriger et ajuster vos données avant injection, ce que Xano ne permet pas toujours de faire avec la précision nécessaire.

Ce que nous migrons

Base de données PostgreSQL : export CSV ou JSON de toutes les tables et leurs données
Schéma des tables : structure, types de champs et relations remappés en entités Doctrine
Fichiers uploadés : assets stockés dans Xano migrés vers le stockage cible
Endpoints API : cartographie des routes documentées pour reconstruire les contrats d'API
Function Stacks : logique analysée et réécrite en services Symfony avec couverture de tests

Export et analyse

Export complet depuis Xano, analyse de la structure et mapping vers le modèle de données cible du logiciel sur mesure.

Import avec validation

Contrôle qualité avant injection : doublons, relations manquantes et données incomplètes sont signalés avant tout enregistrement.

Migration progressive si besoin

Cohabitation possible entre les deux systèmes pendant la transition : vous basculez fonctionnalité par fonctionnalité.

Étape 3 : Bascule

Transition en parallèle, sans rupture de service

Le logiciel sur mesure est développé pendant que vous continuez à travailler dans Xano. Vos équipes basculent quand elles sont prêtes, à leur rythme.

Pas de date butoir imposée : vous gardez le contrôle du calendrier et décidez du moment où chaque module entre en production.

Nous déployons les fonctionnalités au fur et à mesure qu'elles sont prêtes, ce qui permet une migration et une amélioration progressives. Vos équipes se forment sur le terrain, et leurs retours alimentent directement les ajustements des modules suivants.

Développement en parallèle

Le logiciel est construit pendant que votre équipe continue sur Xano, sans interruption d'activité.

Formation progressive

Prise en main accompagnée, aide contextuelle intégrée dans le logiciel, montée en compétence sans stress.

Bascule à votre rythme

Vous décidez du moment de la bascule complète. Pas de date imposée, pas de rupture opérationnelle.

Nos engagements

Ce que vous pouvez exiger de nous

Propriété totale du code source

Vous êtes pleinement propriétaire du code que nous développons pour vous et pouvez maîtrisez son évolution.

Développement 100 % en France

Équipe est basée en France, communication simplifié sans décalage horaire pour une bonne compréhension.

Hébergement cloud souverain

Déploiement sur une infrastructure française avec support réactif. Vos données restent en France.

Pour aller plus loin

Approfondir votre réflexion

Notre méthode de développement sur mesure

De la conception au déploiement, découvrez comment nous développons des logiciels métier qui s'adaptent à vos processus, pas l'inverse.

Valider avant de tout développer

Avant de migrer complètement, un prototype vous permet de valider vos choix fonctionnels avec vos équipes, à moindre coût.

FAQ

Les réponses à vos questions

Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !

Les données PostgreSQL sont exportables en CSV ou JSON sans perte. La Function Stack, en revanche, ne s'exporte pas : c'est un format visuel propriétaire. Nous analysons vos workflows bloc par bloc et les réécrivons en services applicatifs couverts par des tests. La migration prend plus de temps que pour les données seules, mais rien n'est perdu.

Sur 3 ans, le plan Pro représente environ 8 100$, sans posséder ni le code ni l'infrastructure. Un logiciel sur mesure est un investissement unique dont vous êtes propriétaire : pas d'abonnement mensuel, pas de surcoût si votre équipe grandit, et le code vous appartient si vous changez de prestataire.

Oui. Si certains workflows Xano fonctionnent bien et ne sont pas critiques, il est possible de les conserver et de développer uniquement les modules qui nécessitent une logique métier avancée, des tests automatisés ou une RBAC plus fine. Les deux systèmes peuvent communiquer via API pendant la transition.

Un premier module fonctionnel est généralement livrable en 4 à 8 semaines. Le délai dépend de la complexité des Function Stacks à réécrire, du nombre de tables à migrer et des intégrations tierces à reconstituer.

C'est exact pour les données : PostgreSQL est un standard ouvert et l'export est possible. Mais la logique applicative dans la Function Stack est entièrement liée à Xano. Si vous migrez, vous gardez vos données mais réécrivez toute la logique métier. Pour une application avec des dizaines de workflows complexes, c'est le vrai coût de la migration.