Service · Développement logicielDéveloppement logiciel
Migrer une base de données sans perdre une ligne, ni une nuit de sommeil
Nous déplaçons vos données de là où elles sont vers là où elles doivent être : d'un Postgres hébergé ou de Supabase vers une base que vous maîtrisez, d'un ancien outil vers une nouvelle plateforme, de tableurs vers une vraie base. Chaque migration est répétée sur une copie, vérifiée ligne à ligne face à la source, et l'ancien système reste disponible jusqu'à votre accord.
Ce que nous faisons pour vous
- L'inventaire des données : tables, volumes, fichiers, utilisateurs et droits, et les applications qui y écrivent
- Un document de correspondance pour les imports depuis un autre outil : quel ancien champ va où, et que deviennent les cas particuliers
- Une répétition sur une copie, chronométrée, avant le vrai déplacement
- Des comptages et des échantillons comparés entre source et cible après chaque étape
- Utilisateurs, rôles, droits et sécurité au niveau des lignes recréés et testés, pas supposés
- Les applications rebranchées sur la nouvelle base, puis surveillées
- Des sauvegardes configurées sur la cible, et un retour arrière documenté
Pour qui
- Pour vous : vous quittez un service de base hébergée pour des raisons de coût, de maîtrise ou de localisation des données
- Pour vous : vous passez d'un ancien outil de réservation, de CRM ou de gestion à une nouvelle plateforme et voulez garder l'historique
- Pour vous : votre vraie base de données est un ensemble de tableurs
- Pas pour vous : la réplication en direct de très grosses bases sans aucune tolérance d'interruption ; nous vous le dirions et le planifierions autrement
Ce que nous avons migré
- Onze bases Supabase déplacées vers un Postgres auto-hébergé.
- Une base clients transférée d'un ancien outil de réservation vers la plateforme de réservation et de relation client que nous avons construite pour un groupe de restaurants, aujourd'hui en service.
- Les données de nos propres plateformes, dont un logiciel de gestion pour organismes de formation en France qui tourne sur Next.js et Postgres.
Les outils, et leurs limites
L'outil pg_dump de PostgreSQL exporte une base de façon cohérente même pendant son utilisation, sans bloquer lecteurs ni écrivains, en SQL ou en formats d'archive que pg_restore sait recharger, y compris en parallèle. Il peut exporter depuis des serveurs plus anciens et restaurer vers des versions plus récentes, mais pas exporter depuis un serveur plus récent que lui. La documentation prévient aussi que restaurer un export exécute du code choisi par les superutilisateurs de la source : nous inspectons donc les exports venus de sources que nous ne maîtrisons pas.
Supabase présente Postgres comme son cœur et documente le déplacement des données avec les outils standard (pg_dump, pg_restore, réplication logique). Son guide liste aussi ce qui ne suit pas tout seul : les rôles et droits doivent être recréés, la sécurité au niveau des lignes réactivée, et la réplication logique ne copie ni les changements de schéma ni les séquences. Ce sont précisément les détails qui cassent une application après une migration : ils figurent sur notre liste de contrôle.
Le déroulement d'une migration
- Figer la photo. Inventaire, volumes, dépendances, ordre de bascule des applications.
- Répéter. Copie complète vers la cible, durées mesurées, problèmes corrigés.
- Vérifier. Comptage des lignes par table, échantillons comparés, requêtes critiques lancées des deux côtés.
- Basculer. Dans un créneau calme, écritures suspendues si besoin, synchronisation finale, applications rebranchées.
- Surveiller. Erreurs et performances contrôlées ; la source gardée en lecture seule jusqu'à votre accord pour la retirer.
Ce dont nous avons besoin de votre part
- Un accès administrateur à la source et à la cible, ou aux personnes qui les détiennent
- La liste des applications et intégrations qui lisent ou écrivent ces données
- Un créneau où une courte pause des écritures est acceptable, si nécessaire
- Votre accord avant l'arrêt de l'ancienne base, et votre décision sur sa suppression
Les questions qu'on nous pose
Combien de temps le site sera-t-il indisponible ?
Souvent pas du tout en lecture. Pour les écritures, nous mesurons la durée réelle pendant la répétition et convenons d'un créneau avec vous ; pour une petite base, il est en général court.
Et si quelque chose se passe mal ?
La source reste intacte et disponible jusqu'à votre accord : revenir en arrière consiste à rebrancher les applications. C'est pour cela que nous répétons d'abord.
Pouvez-vous importer depuis un outil qui n'exporte qu'en CSV ?
Oui. Nous faisons correspondre chaque colonne, nettoyons doublons et formats, importons dans la nouvelle base et vous remettons la liste de ce qui n'a pas pu être rapproché.
Nos données sont-elles copiées ailleurs ?
Seulement vers la cible et vers les sauvegardes que vous approuvez. Les copies de répétition sont supprimées à la fin, avec votre accord.
Sources
- Documentation PostgreSQL : pg_dump (vérifié le 2026-10-06)
- Documentation Supabase : migrer depuis Postgres (vérifié le 2026-10-06)
- Documentation Supabase : sauvegardes de base (vérifié le 2026-10-06)
- Documentation PostgreSQL : sécurité au niveau des lignes (vérifié le 2026-10-06)