N'importe quel éditeur peut écrire un paragraphe sur le respect qu'il porte à vos données. Ça ne coûte rien et ça ne protège rien. La seule version de cette promesse qui vaille quelque chose est structurelle : construire le produit de sorte que l'éditeur soit techniquement incapable de détenir vos données. Cette contrainte a façonné toutes les décisions qui suivent.
Une seule ligne de produit, jamais de fork. À la seconde où vous laissez le déploiement de chaque client dériver, vous avez un cabinet de conseil qui se fait passer pour un produit, et le client dont l'environnement est le plus ancien cesse discrètement de recevoir les correctifs. Chaque compte fait tourner la même release testée. Ce qui change, c'est la configuration — région, domaine, intégrations, feature flags — jamais le code.
Géré doit vouloir dire géré. Livrer un dépôt à quelqu'un en appelant ça de la souveraineté, c'est transférer la facture opérationnelle au client. Nous gardons le pipeline : releases, migrations de schéma, rotation des secrets, supervision, mises à niveau. Vos ingénieurs devraient écrire de la logique métier, pas exploiter une plateforme.
Une porte de sortie ne compte que si elle est réelle. Un chemin de migration qui ne fonctionne que tant que la relation se passe bien n'est pas un chemin de migration. Si nous disparaissons demain, l'infrastructure continue de servir, la base de données continue d'accepter des écritures et votre domaine continue de résoudre — parce que rien de tout cela ne nous a jamais appartenu.
La propriété des données est le socle. Voici la partie que votre équipe ouvre chaque matin — identique, quel que soit le compte cloud dans lequel elle tourne.
Pipelines, enregistrements, contenus et responsabilités dans une seule vue, au lieu d'un tableur réconcilié avec cinq onglets de navigateur. Les dirigeants lisent l'état d'avancement sans le demander. Les opérationnels voient ce qui demande leur attention sans qu'on leur dise.
Votre modèle de données, le premier jour, est une hypothèse. Les tables, les filtres et les relations sont ici faits pour être modifiés à mesure que l'hypothèse s'affine, et les mêmes enregistrements alimentent toutes les vues CRM, tâches et workflows de l'application — changer la forme une fois la change partout.
Du vrai reporting sur un téléphone entre deux réunions, calculé à partir des définitions que la finance et les opérations ont déjà validées sur poste fixe. Des chiffres en direct, pas un tableur exporté mardi dernier.
Basculez les mêmes enregistrements en vue kanban quand la question est de savoir à quelle étape en est un dossier. Affaires, tâches et contenus sur un seul pipeline, ce qui met fin au débat sur l'export qui faisait foi.
Facturation, CRM, outils de productivité, services d'IA. Les données circulent automatiquement dans les deux sens, ce qui supprime la couche de copier-coller et le lent désaccord entre deux systèmes qui se croient chacun la référence.
Dans un produit bring-your-own-cloud, l'ingénierie intéressante n'est pas dans les fonctionnalités. Elle est dans le fait de livrer la même release, chaque semaine, dans des dizaines de comptes qui ne vous appartiennent pas, sans en casser aucun.
postgraph, sur Django et PostgreSQL, pour le relationnel et l'analytique. nodegraph, sur Node et RethinkDB, pour les données en direct et l'événementiel. Ils respectent le même contrat, donc un client peut faire tourner l'un, l'autre ou les deux sans que le front-end voie la différence.
Toute l'empreinte — réseau, base de données, conteneurs, répartition de charge, CDN, certificats, DNS, secrets, configuration — est du Terraform. Elle se monte en une commande et se démonte en une commande, ce qui est aussi ce qui rend la sortie crédible.
L'infrastructure d'abord, puis les backends en parallèle, avec les migrations exécutées sous contrôle comme tâche unique avant la mise en service d'une nouvelle image. Si une migration échoue, la nouvelle image n'atteint jamais le service en production.
« Qu'est-ce qui tourne en production ? » se répond par une version figée, une empreinte d'image et un historique de déploiement que votre équipe plateforme peut remettre à un auditeur. Chaque environnement suit le train de releases au rythme que vous choisissez.
Nous construisons autour d'un pari assez précis sur les prochaines années.
L'IA a rendu la question de la propriété des données urgente plutôt que théorique. Pour être utile, un modèle doit lire les vraies données : les affaires, les documents, l'historique. Toutes les équipes vont découvrir que, sur l'architecture actuelle, le prix d'une IA utile est l'envoi de toute leur histoire opérationnelle à un tiers. Faire tourner le modèle là où les données se trouvent déjà est la seule version qui survive à une vraie revue de sécurité.
La roadmap vise donc à faire de votre compte le meilleur endroit pour ce travail : le choix du modèle sous votre contrôle, une recherche documentaire qui ne sort jamais de votre périmètre, et des agents qui agissent sur vos données via les mêmes permissions et le même journal d'audit qu'un utilisateur humain. Vos données, votre calcul, votre politique.
L'objectif d'ensemble est plus terne et plus important. Nous voulons un logiciel ennuyeux et bien opéré, qu'une équipe régulée peut adopter sans six mois de détour juridique — et être la raison pour laquelle un dirigeant arrête de voir la résidence des données comme ce qui bloque le contrat.
Si vous voulez une plateforme entièrement opérée qui ne prend jamais la garde de vos données, parlons-en.