Aller au contenu

Réalisations

Changemkr : quatre systèmes sont devenus une plateforme

Torn StudioClient: Changemkr

La relation du studio au client

Changemkr est une plateforme dont Torn Studio détient une part. Le studio a occupé le rôle produit de janvier 2025 à juin 2026 — d’abord comme CPO, ensuite à temps partiel — et a construit dans le code en parallèle de ce rôle. Le travail postérieur à juin 2026 appartient à d’autres et ne figure pas ici.

Réponse courte

Torn Studio occupait le rôle produit chez Changemkr et détient une part de la plateforme. Quatre systèmes hérités sont devenus cinq services en exploitation autour d’une autorité de schéma de 63 tables, et huit environnements d’IA partagent un service LangGraph aux prompts versionnés. La page décrit le travail jusqu’en juin 2026, terme de la période du studio.

La commande

Changemkr avait besoin d’une plateforme où enquête, analyse, planification et suivi tenaient ensemble, avec de l’IA sur toute la chaîne. Le produit vivait alors dans quatre bases de code qui avaient grandi séparément et décrivaient les mêmes notions différemment.

Ce qui rendait la tâche difficile

  • La hiérarchie de planification existait sous forme de sept modèles distincts dans une API Django, et le même mot désignait des choses différentes dans les quatre systèmes — une modification demandait quatre interventions par quatre personnes qui lisaient le modèle chacune à sa façon.
  • La couche d’IA parlait son propre vocabulaire, si bien que l’assistant proposait des objets que le plan de travail ne pouvait pas accepter. C’était l’un des deux points bloquants avant le lancement.
  • Les modèles de base de données du service Python étaient maintenus à la main à côté du schéma défini en TypeScript, de sorte que les deux descriptions des mêmes tables pouvaient diverger en silence.

Des chiffres vérifiables

4systèmes hérités réunis
Le rapport de migration du dépôt les énumère un par un, avec ce que chacun possédait et ce qui l’a remplacé. Un script de compilation maintient à zéro les imports qui en viennent.
63tables sous une seule autorité
Dénombrables dans le répertoire de schéma à la limite de juin. Les modèles Python sont produits depuis la même définition, et une barrière fait échouer la compilation dès qu’ils divergent.
8environnements d’IA sur un service
Dénombrables dans le registre des prompts. Chaque environnement porte son modèle, son jeu d’outils et son versionnement de prompts avec retour en arrière en un clic.
80fichiers de spécification de tests
Dénombrables dans le répertoire de tests à la limite de juin. La page cite le nombre de fichiers, car le dépôt a lui-même retiré son taux de réussite de cette période.

Comment cela a été fait

Une autorité de schéma, le reste dérivé

Drizzle définit désormais les 63 tables, et les modèles du service Python sont produits à partir de cette même définition par un script. Une barrière de compilation compare le fichier produit au fichier versionné et échoue en cas d’écart, si bien que deux systèmes décrivant la même table différemment ne peuvent plus être intégrés.

Des frontières de domaine strictes

NestJS possède les données métier — comptes, organisations, enquêtes, plans. Le service Python possède le domaine de l’IA — fils, plongements, mémoire, le superviseur. L’application web appelle les deux directement, et la frontière est écrite en clair dans le fichier d’instructions du dépôt, ce qui en fait une décision que d’autres peuvent suivre.

Sept modèles n’en font plus qu’un

La hiérarchie de planification a été refondue en une table avec un discriminant de type, plus une table pour les résultats clés et une pour les relations. Le vocabulaire a été fermé, et la couche d’IA parle exactement les mots du plan de travail. Le point bloquant correspondant a été levé le dix juin 2026.

Les barrières portent les frontières

Un script maintient à zéro le nombre d’imports venus des systèmes hérités et fait échouer la compilation à la première rechute. Un autre fait échouer le schéma dès que les modèles produits ont divergé. La consolidation tient parce qu’elle est vérifiée à chaque modification.

Technologies

  • NestJS
  • FastAPI
  • Next.js
  • Drizzle ORM
  • SQLAlchemy
  • LangGraph
  • PostgreSQL
  • pgvector
  • BullMQ
  • Azure Container Apps

Jusqu’où va cette preuve

Cela montre que quatre systèmes peuvent être réunis en un seul et tenus ensemble par des barrières. Cela ne dit rien d’un marché : la plateforme n’était pas lancée à la limite de juin, le verdict du journal de préparation du dépôt était déployable sous réserves, et l’une de ces réserves était une tâche de sécurité manuelle qu’aucun code ne referme.

Preuves

Sur quoi repose cet article — une mesure que nous avons faite, une source datée ou une décision et son coût.

  • Mesure

    Combien de tables la seule autorité de schéma définit

    Objet mesuré: Le répertoire de schéma de Changemkr à la limite de juin

    Méthode: Compter les appels à pgTable dans packages/database/src au dernier commit de juin 2026.

    Résultat: 63 tables

  • Décision

    Laisser un seul schéma définir chaque table et en produire les modèles du service Python.

    Ce qu’elle a coûté: Chaque modification de schéma exige désormais une étape de production supplémentaire avant intégration, et un modèle retouché à la main fait échouer la compilation même lorsqu’il est juste.

  • Décision

    Réunir sept modèles de la hiérarchie de planification dans une table à discriminant de type.

    Ce qu’elle a coûté: La base ne sépare plus les types d’objets par des colonnes propres, si bien que les règles sur ce qui peut se trouver où sont remontées dans l’application et demandent leurs propres tests.

Questions fréquentes

Changemkr est-il un client de Torn Studio ?
Le studio détient une part de la plateforme et y a occupé le rôle produit, ce qui figure en haut de la page. La différence compte : une mission pour autrui et un produit que le studio possède en partie sont deux affirmations distinctes, et vous devez savoir laquelle s’applique avant les résultats.
Pourquoi le cas s’arrête-t-il en juin 2026 ?
Le rôle produit du studio courait jusque-là. La plateforme a continué d’évoluer ensuite sous d’autres mains, et compter ce travail reviendrait à s’attribuer le mérite d’autrui. Chaque chiffre de la page est mesuré à cette limite et vérifiable là.
Pourquoi aucun taux de tests réussis n’est indiqué ?
Le dépôt a remesuré sa suite de tests en août 2026 et a retiré le chiffre antérieur comme invalide. Un nombre que la source elle-même a retiré n’a pas sa place ici, donc la page cite ce qui était stable à la limite : tables, services, environnements d’IA et fichiers de test.
Que signifie une autorité de schéma en pratique ?
Qu’une seule définition contient les 63 tables et que tout le reste en dérive. Les modèles du service Python sont produits par un script, et une barrière fait échouer la compilation dès que le fichier produit et le fichier versionné divergent. Deux systèmes décrivant la même table différemment deviennent alors impossibles à intégrer.
Quelle part du code le studio a-t-il écrite ?
Le studio a construit une large part du produit sur la période et a formulé la plupart des idées et des fonctionnalités, tandis que d’autres travaillaient aussi dans le code. La page affirme donc un rôle et une période, et les chiffres décrivent le système livré à la limite.

Dites-nous ce que vous voulez construire

Trente minutes, sans frais, et une réponse franche sur le fait que nous soyons ou non le bon studio.

Réponse sous 24 heures, une proposition écrite à prix fixe sous trois jours, et vous décidez à votre rythme.

Garantie de satisfaction