Un prompt peut-il remplacer Albato ?

Construis un synchroniseur de fiches bidirectionnel entre exactement deux API choisies par l’utilisateur. Pas une plateforme d’automatisation généraliste.

Connexions : deux services nommés, chacun avec ses identifiants chiffrés au repos et une configuration OAuth ou clé API documentée. Traite chacun comme un petit module adaptateur implémentant quatre opérations : lister les fiches modifiées depuis un curseur, lire une fiche, créer une fiche, mettre à jour une fiche. Tout le reste du système fonctionne contre cette interface, donc ajouter un troisième service plus tard signifie écrire un seul adaptateur.

Correspondance : une carte de champs entre les deux schémas, éditée dans l’interface, avec une direction par champ (A vers B, B vers A, ou les deux) et une expression de transformation optionnelle. Montre un aperçu en direct d’une vraie fiche transformée dans les deux sens avant que la correspondance soit sauvegardée.

Identité : une table de liaison stockant la paire d’identifiants pour chaque fiche synchronisée plus un hash de la dernière valeur connue de chaque côté. Cette table est le cœur du système. Une fiche sans contrepartie est créée ; une fiche avec une contrepartie est comparée.

Détection de changement : interroge chaque côté en utilisant son propre curseur de changement là où il existe, et retombe sur une requête « modifié depuis » là où il n’existe pas. Enregistre le curseur après un passage réussi pour qu’un redémarrage ne rejoue pas tout.

Les conflits, là où une synchro naïve détruit des données en silence. Quand les deux côtés ont changé depuis le dernier passage réussi, ne devine pas. Applique la stratégie configurée par correspondance : le plus récent gagne, le côté A gagne, le côté B gagne, ou mise en attente pour revue. En mise en attente, écris les deux versions et un diff champ par champ dans une file de conflits, et ne synchronise rien pour cette fiche tant qu’un humain n’a pas choisi. N’écrase jamais silencieusement le côté perdant sans enregistrer ce qu’il contenait.

Journal d’exécution : chaque passage enregistre ce qu’il a lu, ce qu’il a écrit, ce qu’il a ignoré et pourquoi, et chaque conflit. Toute écriture doit être reproductible depuis le journal. Prends en charge le rejeu d’une seule fiche en échec sans relancer tout le passage.

Sécurité : un mode simulation qui journalise chaque écriture prévue sans l’exécuter, et une limite de débit stricte par service avec recul exponentiel. Exige qu’une simulation réussisse avant qu’une correspondance puisse être activée pour la première fois.

Hors périmètre : un constructeur de workflow visuel, une logique conditionnelle ou de branchement, plus de deux services dans une même synchro, et tout déploiement multi-tenant hébergé.