kPivot

Le problème de départ

Une migration de données rate rarement sur le transfert. Elle rate sur ce qui l'entoure.

• Le script qui a chargé les données la première fois ne dit pas ce qu'il a écrit, ni ce qu'il a laissé de côté.
• Relancé après une correction, il duplique ce qui était déjà passé — ou il faut vider la cible et tout refaire.
• Interrompu à la quatre cent millième ligne, il recommence à la première.
• Les lignes refusées finissent dans un journal que personne ne relit : le manque apparaît des mois plus tard, en cherchant un dossier client.
• Le suivi du chantier — vagues, gel des saisies, bascule, recette — vit dans un tableur à côté, sans lien avec ce qui s'est réellement exécuté.

Ce que kPivot fait aujourd’hui

Tout ce qui suit fonctionne sur les migrations d'enregistrements — bases de données, fichiers, API, moteurs de recherche : tout ce que les connecteurs du socle Kore savent lire et écrire. Les écrans montrés en démonstration s'appuient sur un jeu entièrement fictif : une entreprise inventée, ses systèmes inventés, ses exécutions et ses rejets synthétiques.

Un plan, et ce qu’il déclare

Un plan de migration nomme une source, une cible, une correspondance de champs et une règle de rejeu. Il déclare aussi la taille des lots, le nombre de lignes transformées en parallèle, la part de rejets au-delà de laquelle une exécution doit s'arrêter, et s'il s'agit d'une simulation. Le plan est inerte : c'est son exécution qui écrit. Il se clone — la deuxième vague est souvent la première avec un autre filtre — et se retire du catalogue par archivage plutôt que par suppression, parce que ses exécutions sont la preuve de ce qui est arrivé aux données de production.

Quatre façons de lire la source

Complet : toute la source, à chaque exécution. Partiel : un sous-ensemble déclaré — une vague, une liste d'identifiants, les rejets corrigés. Incrémental : ce qui a changé depuis le repère de date laissé par la dernière exécution réussie, pour les synchronisations nocturnes de la période où les deux systèmes vivent côte à côte. Continu : un flux, quand la source sait en produire un. Les quatre se composent sur un chantier réel, et se rejouent dans l'ordre choisi.

Rejouer sans dupliquer

C'est la question qui décide de tout le reste. Trois réponses possibles, déclarées par le plan : la clé naturelle de la cible, qui met à jour au lieu d'insérer ; le journal de pivot, qui retient pour chaque objet source l'objet cible qu'il est devenu ; ou aucune, réservée à une cible vide et à une seule exécution — et qui doit être choisie explicitement, jamais par défaut.

Une simulation qui n’écrit rien

Une exécution en simulation lit et transforme pour de vrai, puis n'écrit pas. Elle produit les mêmes compteurs, les mêmes rejets et les mêmes diagnostics qu'une exécution réelle : c'est une répétition générale, pas un aperçu. Une simulation peut aussi être forcée au lancement d'un plan réel ; l'inverse n'est pas possible : repasser en écriture réelle demande de modifier le plan.

Un point de reprise à chaque lot

Chaque lot validé écrit son point de reprise : où en est la lecture de la source, la date atteinte et le numéro du lot. Une exécution interrompue — coupure réseau, redémarrage, seuil d'erreur franchi — reprend là où elle s'est arrêtée au lieu de tout recommencer. Ce point n'avance qu'une fois le lot écrit pour de bon : une interruption fait relire des lignes, jamais sauter.

Un seuil d’erreur qui arrête vraiment

Au-delà de la part de rejets déclarée par le plan, l'exécution s'arrête sur un lot propre plutôt que de produire des données fausses à grande échelle. Le plan peut exiger l'arrêt au premier rejet, ou ne jamais s'arrêter — c'est un choix, et il est écrit dans le plan.

Des rejets exploitables

Chaque ligne refusée garde la phase où elle est morte — lecture, transformation, validation, écriture —, un code de motif stable pour les regrouper, un message lisible et un diagnostic. L'écran des rejets les ventile par motif : quatre cents rejets qui partagent une cause sont un correctif à faire, pas quatre cents décisions à prendre. La ligne d'origine est conservée telle qu'elle a été lue, pour que le rejeu ait de quoi repartir ; elle ne ressort jamais par l'API et aucun écran ne l'affiche — promener une donnée personnelle qu'on ne montre nulle part serait un risque pris pour rien.

La conduite du chantier au même endroit

Projets, vagues, tâches et anomalies sont des objets du socle Kore, avec leurs cycles de vie : un projet va du cadrage à la bascule puis à la vérification, une vague de la planification au contrôle des écarts — ou au retour en arrière. Listes, kanban, frise et « mes tâches » s'appuient dessus, avec affectations, minuteur et historique. Un plan de migration se rattache à son projet : ce qui s'est exécuté et ce qui reste à décider ne sont plus dans deux outils différents.

Les correspondances de champs, et la migration retour

La transformation n'est pas réinventée : les correspondances de champs sont celles du socle Kore, partagées avec les autres applications, avec leur validation, leurs tables de conversion et — ce qui compte le jour d'un retour arrière — leur inversion. Un plan de retour est le plan d'aller avec sa correspondance inversée.

Le journal de pivot, objet par objet

Les compteurs d'une exécution disent que quatre cent mille lignes sont passées. Le journal de pivot dit que ce ticket-là est devenu celui-ci, par quelle correspondance et dans quel sens. C'est la trace qui permet de répondre à une question précise des mois après, et c'est aussi ce que lit la règle de rejeu fondée sur le journal.

Les tendances, pas seulement l’instant

Une migration au long cours rejoue le même plan des dizaines de fois. Le volume traité, les rejets et la durée de chaque plan sont mesurés à chaque exécution et conservés : la baisse des rejets d'une semaine à l'autre se lit sur une courbe, comme l'allongement progressif d'une exécution. Des tableaux de bord prêts à ajouter évitent de partir d'une page blanche.

Une API unique, et un accès pour les assistants

Tout ce que font les écrans passe par la même API GraphQL, sous les mêmes permissions et la même séparation étanche entre organisations. Trois outils exposés aux assistants donnent l'état des plans, des exécutions et des rejets en lecture seule : un agent peut dire où en est la reprise sans pouvoir la déclencher.

Ce que l’exploration a montré

kPivot est né d'un constat interne : chaque reprise de données réécrivait son propre script, et aucune ne laissait de trace exploitable. La question était de savoir si le socle Kore permettait d'en faire un outil.

Questions fréquentes