Mais ces deux semaines m’ont déjà appris une chose. Sur une application qui a de l’histoire, ce qu’il faut savoir pour corriger un bug n’est presque jamais dans le code. C’est dans le plan batch, dans les logs d’une tâche automatisée, dans une table, dans la page qui décrit ce qu’une autre application attend de la nôtre. Un agent qui ne voit que le dépôt devine. Je voulais un agent qui aille vérifier.

Alors avant de lui confier quoi que ce soit, j’ai passé du temps à lui apprendre où chercher.

Trois étages

Rien d’exotique : des fichiers texte et quelques gestes rangés.

• Un CLAUDE.md, partagé par l’équipe. L’architecture, les conventions du projet, et surtout les liens vers les pages de flux de notre Confluence, dont il garde le contenu sous la main : ce que l’application reçoit, ce qu’elle envoie, à qui, et qui dépend d’elle.
• Un CLAUDE.local.md, propre à mon poste. Comment se brancher aux bases et aux machines depuis mon poste. Hors production, sans exception.
• Des skills, pour les gestes qui reviennent. Retrouver un flux et ce qui l’entoure. Préparer une livraison, scripts de migration compris — ceux de la note précédente.

Il sait aussi comment tourne la maison : notre back-office suit un plan batch précis, marché par marché, et il sait où retrouver les logs de chaque tâche automatisée.

Le résultat, c’est qu’il ne part plus d’une page blanche. Face à un bug, il se fabrique son contexte lui-même : il lit le plan, ouvre les logs, regarde en base, relit le flux concerné. Exactement ce que je ferais, dans le même ordre.

Un bug, pour voir

Le métier nous remonte un problème : aucun message n’est généré pour le service d’éditique, c’est-à-dire l’imprimeur.

Le contexte tient en trois lignes. Nos bases sont multi-pays. L’export vers l’éditique est un job qui ramasse en base les messages disponibles et en fait un fichier ; il est lancé une fois par marché. Pendant longtemps il n’y a eu qu’un marché. Nous venions d’en ajouter deux.

Trois marchés, donc trois exécutions, à cinq minutes d’intervalle :

T          export --market=A   -> picks up every pending message, flags them all as A
T + 5 min  export --market=B   -> nothing left to export
T + 10 min export --market=C   -> nothing left to export

Le paramètre qui indique le marché existait bien. Il ne servait qu’aux logs. Il ne filtrait rien.

// Simplified. Before: the market only reached the logs.
log.info("Export started for market {}", market);
List<Message> pending = messageRepository.findPending();

// After: the market decides what the job is allowed to take.
List<Message> pending = messageRepository.findPendingByMarket(market);

Tant qu’il n’y avait qu’un marché, ce code était juste. Il l’est resté longtemps. Le jour où deux pays sont arrivés, la première exécution a tout pris, tout étiqueté à son nom, et les deux suivantes ont tourné à vide. C’est le genre de bug que le code hérité fabrique tout seul : rien n’a cassé, c’est le monde autour qui a changé.

Ce que Claude Code m’a rendu, ce n’est pas seulement la ligne à corriger. C’est l’histoire complète : l’historique du plan batch et de ses trois exécutions, ce qui était disponible comme messages à ce moment-là, la cause, le correctif proposé, et un plan de rattrapage pour les messages étiquetés au mauvais marché.

Le correctif tient en une ligne. Tout le reste est du contexte, et c’est ce reste qui prend du temps quand on le reconstitue à la main.

Où je mets la limite

Il propose. La décision reste la mienne, et certaines portes restent fermées.

Pas de production. Ses accès s’arrêtent aux autres environnements. Ce n’est pas un réglage que j’ajusterai quand j’aurai davantage confiance : c’est une porte qui ne s’ouvre pas.

Je lis en ce moment deux textes qui m’aident à mettre des mots là-dessus. Addy Osmani décrit le développeur qui devient le manager de ses agents : le plus difficile n’est plus d’écrire le code, c’est de bien confier le travail et de vérifier ce qui revient. Et un long texte sur les boucles et les graphes d’agents défend une idée que je trouve très juste : on ouvre les vannes selon ce que coûte une erreur, pas selon l’assurance affichée par le modèle.

J’en garde trois règles, pour la suite :

• Le contrôle d’abord. « Ça a l’air bon » n’est pas une vérification. Il faut quelque chose qui puisse échouer : un test, un cas rejoué sur une base de recette.
• La réversibilité décide. Une correction isolée se défait d’un revert. Une migration, une suppression, une écriture sur des données de production ne se défont pas : celles-là, il les prépare, quelqu’un les relit, quelqu’un d’autre les passe.
• Une cause confirmée devient une règle. Ce bug doit laisser une trace dans le CLAUDE.md : un paramètre de job qui ne filtre rien est suspect. Sinon je le recroiserai.

Ce que j’en retiens

Un agent vaut ce que vaut le contexte qu’on lui laisse trouver.

Je n’ai pas gagné du temps parce qu’un modèle écrit du Java plus vite que moi. J’en ai gagné parce que j’ai écrit, une fois, ce que je sais de cette application et où se trouve le reste — ce que j’aurais dû écrire de toute façon, pour le prochain collègue qui arrive.

Deux semaines, donc. Trop tôt pour dire ce qui tiendra. Je reviendrai ici dans quelques mois, avec ce qui a raté.

Les mises en production fonctionnaient. Magiquement. Ou pas toujours. Et quand elles ne fonctionnaient pas, l’équipe d’exploitation découvrait le sujet en même temps que l’incident : elle n’avait pas été impliquée, puisqu’il n’y avait rien à lui confier.

Ce n’est pas un procès. C’est une habitude qui s’installe sans bruit dans une équipe qui connaît sa base par cœur, et qui tient tant que les mêmes personnes sont là. Mais elle a un coût, et il est toujours payé le jour de la mise en production.

Ce que le SQL à la main coûte

• Personne ne sait ce qui a été livré. L’état de la base est la somme de gestes dont il ne reste aucune trace. La question « qu’est-ce qui a changé depuis la dernière fois ? » n’a pas de réponse.
• Les environnements dérivent. Un script passé en recette et oublié en production, un autre corrigé au vol sur un seul environnement : ce qu’on teste n’est plus ce qu’on livre.
• Le code et la base ne sont plus synchronisés. Une version de l’appli attend une colonne ; rien ne garantit qu’elle existe là où on la déploie.
• La production devient une affaire d’initiés. Ceux qui savent passent les scripts, les autres regardent. L’exploitation, qui porte pourtant la disponibilité, est tenue à l’écart de ce qui la menace le plus.

Le principe : un changement, un fichier

Flyway est un outil de migration de base de données, et son idée est d’une simplicité désarmante. Chaque modification du schéma est un fichier SQL, numéroté, rangé dans le dépôt à côté du code :

db/migration/
  V1__baseline.sql
  V2__add_delivery_note_to_orders.sql
  V3__create_order_history_table.sql

-- V2__add_delivery_note_to_orders.sql
ALTER TABLE orders ADD COLUMN IF NOT EXISTS delivery_note VARCHAR(255);

CREATE INDEX IF NOT EXISTS idx_orders_delivery_date ON orders (delivery_date);

Dans chaque base, Flyway tient une table d’historique : quelles migrations ont été jouées, quand, par qui, avec quelle empreinte. À l’exécution, il compare les fichiers à cet historique et ne joue que ce qui manque, dans l’ordre.

La conséquence est immédiate : la production ne reçoit plus que des scripts qui ont déjà tourné, à l’identique, sur les environnements précédents. La mise en production cesse d’être une première fois.

Partir d’une base qui existe déjà

On ne met pas en place Flyway sur une page blanche. La base est là, avec son passé, et parfois avec des environnements qui ne se ressemblent plus tout à fait.

Le point de départ s’appelle une baseline : on déclare l’état actuel comme la version 1, sans rien rejouer, et tout ce qui suit passe par des migrations. C’est aussi le moment de comparer les schémas entre environnements et de résorber les écarts — un travail ingrat, mais qu’on ne fait qu’une fois.

Les règles qui vont avec

L’outil ne suffit pas. Ce qui change les choses, ce sont quelques règles tenues sans exception.

• Plus aucun SQL de structure à la main. Si ce n’est pas dans une migration, ça n’existe pas. La règle vaut aussi pour les urgences — surtout pour les urgences.
• Une migration jouée ne se modifie plus. Flyway vérifie l’empreinte de chaque fichier : toucher à un script déjà appliqué bloque la suite. Pour corriger, on écrit la migration suivante.
• Les scripts sont relus comme du code. Même dépôt, même revue, même historique. Le changement de schéma voyage avec la version de l’appli qui en a besoin.
• Un script doit pouvoir être rejoué sans dégât. IF NOT EXISTS, IF EXISTS : une migration idempotente ne casse rien si elle retombe sur une base où le changement est déjà là — ce qui arrive forcément quand on part d’environnements modifiés à la main.
• On corrige vers l’avant. Pas de retour arrière improvisé en production : le plan de repli se prépare, s’écrit et se relit avant la livraison.

Des règles tenues par le pipeline

Une règle qui repose sur la vigilance de chacun finit par céder, un vendredi soir. Celles-ci sont donc portées par GitLab, avec deux jobs.

Le premier est un contrôle, qui tourne à chaque modification : il vérifie que les scripts respectent les règles de nommage, et qu’ils sont idempotents. Un fichier mal nommé, Flyway l’ignore en silence ; un script non rejouable, on le découvre en production. Autant que ce soit le pipeline qui le dise, avant la relecture.

Le second est le job de migration : un validate, puis un migrate.

stages: [check, migrate]

check-migrations:
  stage: check
  script:
    - ./ci/check-naming.sh db/migration       # V<version>__<description>.sql
    - ./ci/check-idempotence.sh db/migration  # safe to run twice

migrate:
  stage: migrate
  when: manual
  script:
    - flyway validate   # do the files still match what was applied?
    - flyway migrate    # apply pending migrations, in order

Le validate refuse d’aller plus loin si un script déjà appliqué a été modifié ou s’il en manque un. Le migrate ne joue que ce qui reste à jouer.

Rendre la production à ceux qui l’opèrent

Le versioning n’était que la moitié du chantier. L’autre moitié, la plus utile, a été de former l’équipe d’exploitation à exécuter ces migrations elle-même.

Concrètement, c’est elle qui lance le job de migration. Avant de livrer, elle voit exactement ce qui va être joué : la liste des scripts est dans le dépôt, relue et contrôlée. Après, le journal du job et la table d’historique disent ce qui l’a été. Elle n’exécute plus un geste qu’on lui dicte : elle opère un outil qu’elle comprend, sur une liste qu’elle peut lire.

Et pour l’équipe de développement, c’est une discipline salutaire : un script que quelqu’un d’autre va passer s’écrit avec plus de soin qu’un script qu’on passe soi-même, tard, en se disant que ça ira.

Un historique qui ne ment pas

Je n’avais pas anticipé à quel point ce dossier de migrations deviendrait une documentation. Chaque fichier dit ce qui a changé, son nom dit pourquoi, et l’historique du dépôt dit qui, quand, et pour quelle livraison. La table d’historique, elle, dit ce qui tourne réellement sur chaque environnement.

Contrairement à un schéma dessiné dans un wiki, celui-là ne peut pas être en retard : c’est lui qui fait la base.

Ce que j’en retiens

La production est l’affaire de tous.

Pas celle de quelques-uns qui savent, ni celle d’une équipe qui subit. Livrer, c’est être transparent sur ce que l’on livre : pouvoir le montrer avant, le vérifier après, et le retrouver dans six mois.

Flyway n’a rien de spectaculaire. C’est un dossier de fichiers numérotés, une table et deux jobs. Mais c’est souvent ça, une bonne pratique : rendre visible ce qui se faisait dans l’ombre, et confier à chacun la part qui lui revient.

Jusque-là, rien d’exotique. Ce qui a compliqué l’affaire, c’est l’endroit où vit l’application : elle n’est pas ouverte dans un onglet, elle est embarquée dans l’outil de support des agents, dans une iframe.

Ce que l’iframe casse

Une connexion OIDC classique repose sur des redirections : l’appli envoie le navigateur chez le fournisseur d’identité, qui le renvoie une fois l’utilisateur authentifié. Dans une iframe, cette mécanique se grippe à deux endroits.

• Les redirections sont bloquées. Les pages de connexion refusent d’être affichées dans un cadre — c’est une protection contre le détournement de clic, et elle est légitime. Impossible, donc, de dérouler le login à l’intérieur de l’iframe.
• Les cookies ne suivent plus. Vue du navigateur, notre appli est un contenu tiers dans la page de l’outil de support. Son cookie de session est un cookie tiers, et les navigateurs les bloquent de plus en plus.

Restait une question très concrète, à laquelle nous n’avions pas de réponse toute faite : si le login se passe ailleurs, comment faire revenir le résultat jusqu’à l’iframe ?

La cinématique retenue

La réponse tient en trois pièces : une fenêtre à part, un message, un cookie partitionné.

L’iframe ouvre le login dans une popup. Dans cette fenêtre, plus de cadre : les redirections vers le fournisseur d’identité fonctionnent normalement, et le backend termine le flux OIDC comme il le ferait pour n’importe quelle appli web. La popup prévient ensuite l’iframe avec postMessage, puis se ferme.

// Inside the iframe: open the login in a popup, then wait for its answer.
const popup = window.open(`/login/${provider}`, "login", "popup,width=480,height=640");

window.addEventListener("message", async (event) => {
  // only our own popup, on our own origin
  if (event.origin !== window.location.origin || event.source !== popup) return;

  // a one-time code travels between windows, never the tokens themselves
  await fetch("/session", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ code: event.data.code }),
  });
  startApp();
});

Ce qui transite entre les deux fenêtres n’est pas un jeton, mais une preuve à usage unique et à durée de vie très courte. L’iframe l’échange auprès du backend, qui répond en posant le cookie de session — et c’est parce que ce cookie est posé depuis l’iframe qu’il peut être partitionné :

Set-Cookie: __Host-session=…; Path=/; Secure; HttpOnly; SameSite=None; Partitioned

Un cookie partitionné (CHIPS) n’existe que pour le couple « notre appli, embarquée dans cet outil de support ». Il ne permet aucun pistage d’un site à l’autre, ce qui lui vaut d’être accepté là où un cookie tiers classique est refusé. Les jetons, eux, ne quittent jamais le backend.

Trois précautions vont avec :

• Vérifier l’origine de chaque message reçu, des deux côtés. Un postMessage sans contrôle d’origine est une porte ouverte.
• Limiter qui peut nous embarquer : l’appli n’accepte d’être affichée que dans l’outil de support (frame-ancestors), nulle part ailleurs.
• Protéger contre le CSRF pour de bon. Avec SameSite=None, le navigateur ne fait plus ce travail à notre place.

Entra ID ne joue pas les brokers

Toute cette cinématique, il faut la faire fonctionner pour chaque fournisseur d’identité. D’où l’envie, très vite, de n’en avoir qu’un seul face à l’appli.

Le candidat naturel était Entra ID : c’est l’annuaire du groupe, et il est opéré par une vraie équipe IAM. Mais Entra ID ne sait pas se placer devant un autre fournisseur comme simple relais. Il sait fédérer un fournisseur externe, à une condition : que chaque utilisateur existe aussi chez nous, sous forme de compte invité (B2B).

C’est la solution la plus propre côté code — l’appli ne parle plus qu’à un émetteur. Le prix est ailleurs : le cycle de vie de ces comptes invités devient notre affaire. Avec une population de centre de contact et le turnover qui va avec, nous l’avons écartée.

Restaient deux options.

Option 1 : notre propre Keycloak

Un Keycloak chez nous, en identity broker : l’appli ne connaît que lui, et c’est lui qui va chercher l’utilisateur chez Entra ID ou chez le prestataire.

Les avantages sont réels :

• Un seul flux à faire marcher dans l’iframe. La popup, le message, le cookie : tout est réglé une fois, pour un seul émetteur.
• Une appli plus simple. Une configuration, un contrat de claims, et la fédération d’identités rangée dans le composant dont c’est le métier.
• Réutilisable. La prochaine appli qui devra accueillir ce prestataire n’aura rien à refaire.

Le défaut tient en un mot : gouvernance. Un broker est un composant critique — haute disponibilité, base de données, montées de version, correctifs de sécurité — et un point de panne commun aux deux populations : s’il tombe, plus personne ne se connecte. Il lui faut un propriétaire.

Or nous avions justement un Keycloak dans le service. Il tournait, mais il n’était réellement opéré par personne. Chez nous, seul Entra ID est porté par l’équipe IAM. Bâtir l’accès de tout un service client sur un composant orphelin, ou monter une exploitation digne de ce nom dans le budget et les délais d’un projet : ni l’un ni l’autre n’était raisonnable.

Option 2 : l’appli gère les deux

L’application back-office parle directement aux deux fournisseurs. Pas de nouveau composant, pas de nouvelle dépendance à exploiter, et des pannes cloisonnées : un incident chez le prestataire ne bloque pas nos collaborateurs, et inversement.

Les défauts sont le miroir exact de l’option 1 :

• Deux flux à faire marcher dans l’iframe, avec deux fournisseurs qui n’ont pas les mêmes réglages ni les mêmes interlocuteurs.
• De la logique d’identité dans l’appli : deux configurations, deux formats de claims à normaliser.
• Rien de réutilisable. La prochaine appli refera le même travail.

Ce que le multi-IdP demande à l’appli

Pour que ce choix reste vivable, l’essentiel est d’empêcher les deux fournisseurs de se répandre dans le code.

• Un seul type d’utilisateur en sortie. Chaque fournisseur a son convertisseur, et les deux produisent le même objet métier : interne ou externe, rôles de l’appli. Passé la connexion, rien ne doit savoir d’où vient l’utilisateur.
• Un identifiant composé : le couple émetteur et identifiant. Côté Entra ID, l’identifiant d’objet et le tenant plutôt que le sub, qui change d’une application à l’autre.
• Des rôles d’application plutôt que des groupes côté Entra ID : un claim lisible, sans identifiants opaques ni limite de taille. Côté prestataire, des rôles déclarés sur le client.
• L’autorisation reste une règle métier. Un agent du prestataire n’a pas les mêmes droits qu’un collaborateur, et ce n’est pas au fournisseur d’identité d’en décider.
• Les jetons s’arrêtent au backend. Les services en aval sont appelés avec l’identité de l’appli et l’utilisateur normalisé, sinon chacun hérite du multi-IdP.

Ce que j’en retiens

Nous avons choisi le multi-IdP. Pas parce que c’est la meilleure architecture dans l’absolu : parce qu’il n’existait pas, côté groupe, de solution de fédération solide sur laquelle s’appuyer. À l’heure où j’écris, les tests d’intégration sont en cours, et en bonne voie.

Les deux options se valent sur le papier. Ce qui les départage n’est pas technique : c’est qui opère quoi.

• Une équipe pour porter un broker → le broker. C’est là que la fédération doit vivre, et chaque nouvelle appli en profite.
• Personne pour le porter → le multi-IdP dans l’appli, proprement isolé. Mieux vaut un peu de complexité dans un code qu’on maîtrise qu’un composant critique sans propriétaire.
• Une population externe stable → les comptes invités, qui simplifient tout le reste.

Et le jour où une solution groupe existera, la migration sera courte : si l’appli ne connaît qu’un seul type d’utilisateur, remplacer deux fournisseurs par un seul ne touche que la porte d’entrée.