Elie Nehmé
Contact

Publications

Un radar technologique trimestriel: installer, versionner, décider

Le radar open source de Zalando, quatre quadrants renommés, une édition taguée par trimestre et des changements d’anneau fondés sur des preuves, jamais sur la popularité

Dans une grande organisation, la même question revient d’un projet à l’autre: quelle technologie un nouveau projet a-t-il le droit d’utiliser? Sans réponse écrite, chaque équipe la tranche seule, et rien ne garantit que deux équipes la trancheront de la même façon, ni que la raison du choix sera encore connue un an plus tard.

Un radar technologique répond à cette question sur une seule page. Il range chaque technologie dans un domaine et dans un anneau, du recommandé au déconseillé. J’en ai mis en place plusieurs, chaque fois à la demande d’une DSI: une démarche lancée d’en haut, pas née des équipes. Celui que décrit cet article date de 2022, pour l’écosystème d’une grande organisation, avec le radar open source de Zalando. L’outil s’installe vite. Ce qui demande du soin, c’est le reste: où vivent les entrées, comment une édition se publie, et qui a le droit de déplacer une technologie d’un anneau à l’autre.

Pourquoi partir du radar de Zalando

Zalando publie son propre radar et le code qui le dessine, sur GitHub, sous licence MIT. Le dépôt s’inspire du radar de ThoughtWorks et se réduit à l’essentiel: un fichier radar.js, construit sur d3.js version 4, qui expose une seule fonction, radar_visualization(). Elle prend une configuration et dessine le radar dans une balise svg. Pas de serveur, pas de base de données: une page HTML statique.

C’est exactement ce qu’il fallait. Une page statique s’héberge partout, se génère dans un pipeline et se versionne avec Git. La version publiée en janvier 2022, radar-0.6.js, ajoute un lien optionnel sur chaque entrée, utile pour renvoyer vers la fiche qui justifie la décision.

Installer: une page, une fonction

L’installation tient en trois étapes, celles du README: charger d3.js et radar.js, poser une balise <svg id="radar">, appeler la fonction. Pour un site interne, on copie le fichier radar-0.6.js dans le dépôt plutôt que de le charger depuis l’extérieur.

<script src="d3.v4.min.js"></script>
<script src="radar-0.6.js"></script>

<svg id="radar"></svg>

<script>
  radar_visualization({
    svg_id: 'radar',
    width: 1450,
    height: 1000,
    colors: { background: '#fff', grid: '#bbb', inactive: '#ddd' },
    title: 'Radar technologique 2022-Q3',
    quadrants: [
      { name: 'Développement et intégration' }, // 0, en bas à droite
      { name: 'Infrastructure et cloud' }, //      1, en bas à gauche
      { name: 'Données et stockage' }, //          2, en haut à gauche
      { name: 'Sécurité et architecture' }, //     3, en haut à droite
    ],
    rings: [
      { name: 'ADOPT', color: '#93c47d' }, // 0, l’anneau intérieur
      { name: 'TRIAL', color: '#93d2c2' },
      { name: 'ASSESS', color: '#fbdb84' },
      { name: 'HOLD', color: '#efafa9' },
    ],
    print_layout: true,
    entries: [
      { label: 'PostgreSQL', quadrant: 2, ring: 0, moved: 0 },
      { label: 'Apache Kafka', quadrant: 2, ring: 2, moved: 0 },
    ],
  });
</script>

Quatre choses à savoir avant de remplir la configuration.

  • Quatre quadrants, quatre anneaux, pas un de plus. La géométrie est fixée dans le code: on renomme les quadrants et les anneaux, on n’en ajoute pas. C’est une contrainte utile: elle oblige à choisir ses domaines.
  • Les indices comptent. Les quadrants sont numérotés de 0 à 3 dans le sens des aiguilles d’une montre, en partant d’en bas à droite. Les anneaux de 0 à 3, de l’intérieur vers l’extérieur: l’anneau 0 est le plus recommandé.
  • moved dit d’où vient l’entrée. 1 dessine un triangle pointé vers le haut (l’entrée a gagné un anneau), -1 un triangle vers le bas, 0 un cercle. Il se lit toujours par rapport à l’édition précédente.
  • Le placement est stable. Chaque point est placé au hasard dans sa case, mais à partir d’une graine fixe: les mêmes entrées, dans le même ordre, donnent la même image.

Quatre anneaux, quatre quadrants à nous

Les quatre anneaux de Zalando ont été gardés. Leurs définitions, elles, ont été écrites pour l’organisation, une ligne par anneau.

  • Adopt: approuvé, recommandé pour les nouveaux projets.
  • Trial: testé dans des conditions réelles et maîtrisées.
  • Assess: en cours d’évaluation.
  • Hold: pas pour un nouveau projet; peut rester dans les systèmes existants.

Les quadrants, eux, ont été renommés. Ceux de Zalando (langages, infrastructure, bases de données, gestion des données) répondent à ses besoins. Ceux de l’organisation suivent ses propres sujets:

  • Développement et intégration: langages, frameworks, API, middleware.
  • Infrastructure et cloud: plateformes cloud, conteneurs, CI/CD, DevOps, observabilité.
  • Données et stockage: bases de données, plateformes de données, messagerie, analytique.
  • Sécurité et architecture: identité, cybersécurité, standards d’architecture, résilience.

Le schéma ci-dessus est un exemple, pas un relevé de décisions. Il montre seulement comment les entrées se lisent: le quadrant dit de quoi il s’agit, l’anneau dit ce qu’on a le droit d’en faire.

Les entrées vivent dans Git, pas dans la page

Le piège, avec un outil aussi simple, est d’éditer le tableau entries à la main dans la page HTML. On perd alors tout ce qui donne sa valeur au radar: la raison de chaque placement, la personne qui en répond, l’historique.

Le radar a donc été construit à partir d’un dépôt Git. Chaque entrée y est une donnée structurée, en JSON ou en YAML, avec son quadrant, son anneau, sa justification (rationale) et son responsable (owner).

# Exemple d’entrée
label: Apache Kafka
quadrant: Données et stockage
ring: Assess
rationale: >-
  Besoin de flux d’événements entre applications, évaluation en cours sur un
  périmètre limité
owner: architecte de domaine Données

La page n’est plus qu’un produit de ces fichiers. Un pipeline lit les entrées, les traduit dans la configuration de radar_visualization() et publie le résultat sur un site interne: GitLab Pages, ou un serveur web interne. Il ne tourne qu’après approbation, sur un tag.

Chaque trimestre se termine par un tag de version: pour 2022, de radar-2022-Q1 à radar-2022-Q4. Avec GitLab Pages, le déclenchement tient en quelques lignes; la seule convention imposée est un job nommé pages qui dépose le site dans public.

pages:
  rules:
    - if: '$CI_COMMIT_TAG =~ /^radar-20[0-9]{2}-Q[1-4]$/'
  script:
    - npm ci
    - npm run build # génère public/index.html à partir des entrées
  artifacts:
    paths:
      - public

Le tag fait plus que déclencher une publication. Il fige les décisions valables à cette date. Quand une équipe demande, un an plus tard, pourquoi un projet a démarré sur une technologie aujourd’hui en Hold, la réponse est dans le tag du trimestre où il a commencé: elle était en Trial, avec telle justification et tel responsable. Et la différence entre deux tags donne, entrée par entrée, la valeur de moved.

Qui propose, qui revoit, qui décide

Un radar sans règles de décision devient le radar de celui qui le maintient. Les rôles sont donc écrits.

  • Une équipe de développement ou un tech lead propose une technologie ou un changement d’anneau.
  • Les architectes de domaine et les spécialistes revoient l’adéquation, la sécurité, le risque opérationnel et la conformité.
  • Le comité d’architecture approuve les décisions significatives et les standards d’entreprise.
  • Le responsable du radar maintient le dépôt et publie les éditions approuvées. Il valide seul les corrections mineures.

Une proposition n’est pas une demande d’ajout en une ligne. Elle décrit le besoin métier, les bénéfices techniques, les alternatives envisagées, les risques, l’expérience de mise en œuvre déjà acquise et l’anneau proposé. Écrire les alternatives oblige à vérifier que la technologie ne double pas une entrée déjà en Adopt.

Changer d’anneau sur preuves

La règle qui compte le plus tient en une phrase: une technologie change d’anneau selon les preuves, sa maturité et son risque, jamais selon sa popularité. Une technologie dont tout le monde parle n’entre pas en Trial parce qu’on en parle. Elle y entre quand quelqu’un a un plan pour l’essayer.

Chaque mouvement porte une justification écrite, un responsable et une date de revue. Et chaque transition a ses conditions:

  • Assess vers Trial: une évaluation prometteuse et un plan de pilote approuvé.
  • Trial vers Adopt: des tests réussis, des preuves en production, l’accord de la sécurité et un support durable.
  • Adopt vers Hold: une fin de support, un risque devenu inacceptable, un coût excessif, ou un standard mieux soutenu qui la remplace.
  • Trial vers Hold: un pilote en échec ou des limites restées sans réponse.
  • Hold vers Assess: de nouvelles capacités, des besoins qui ont changé, ou une stratégie de remplacement crédible.

Ces conditions ont un effet secondaire utile: elles disent à une équipe ce qu’il lui faut réunir avant de proposer. Une demande de passage en Adopt sans preuve en production n’a pas besoin d’aller jusqu’au comité.

Hold n’est pas un arrêt

Le dernier anneau prête à malentendu. Une technologie en Hold n’est pas éteinte le lendemain de la publication: les systèmes existants ne sont pas arrêtés automatiquement. Hold ferme la porte aux nouveaux projets, rien de plus.

Pour ceux qui restent, la règle est écrite. Leurs responsables documentent les dépendances, évaluent les risques, obtiennent une dérogation quand il le faut et planifient la migration ou le retrait. L’usage qui continue est revu périodiquement.

Sans cette règle, Hold devient soit une menace que tout le monde ignore, soit un ordre de migration que personne n’a budgété. Avec elle, c’est une trajectoire.

Une édition, une décision datée

L’outil de Zalando ne fait que dessiner. Ce qui transforme un dessin en référence, c’est ce qui l’entoure: des entrées dans Git avec leur justification et leur responsable, un tag par trimestre qui fige ce qui était valable, un pipeline qui ne publie qu’après approbation, et des règles de mouvement que chacun peut lire avant de proposer.

Un radar publié ainsi répond à deux questions à la fois. Que peut utiliser un nouveau projet aujourd’hui? Et que pouvait-il utiliser le jour où il a commencé?