NextGen IT Stack Radar DACH 2026/H1: Recommandations claires pour les Tech Leads

Marcus, Architecte Solution | NextGen IT

ThoughtWorks publie un Technology Radar depuis 2010.^[6] Nous faisons pareil, mais adapté à la réalité des ETI allemandes, autrichiennes et suisses. Comptez 50 à 250 collaborateurs, une dette technique On-Premise bien réelle, le BSI-Grundschutz comme contrainte réglementaire, un budget qui ne s'aligne pas sur celui d'un hyperscaler. Ce radar n'est pas un catalogue de vœux. C'est un positionnement, et je l'assume pleinement.

Quatre anneaux, comme d'habitude : Adopt, Trial, Assess, Hold. Si vous attendez un « ça dépend » bien lisse, vous lisez le mauvais radar.

Méthode

Chaque classement repose sur trois critères. D'abord les preuves de maturité en production : au moins deux installations de référence dans des ETI DACH. Ensuite la charge opérationnelle rapportée à la valeur générée. Enfin la compatibilité réglementaire (RGPD, BSI IT-Grundschutz, NIS2).^[5] Une précision qui compte : les technologies rangées dans Hold ne sont pas condamnées. Elles ne reçoivent simplement plus de nouveaux investissements. La nuance est importante.

ADOPT: À déployer maintenant, aucune attente supplémentaire justifiable

Platform Engineering avec une Internal Developer Platform (IDP)

Martin Fowler l'anticipait dès 2003 dans Patterns of Enterprise Application Architecture : une infrastructure qui se comporte comme un produit réduit durablement la charge cognitive des équipes de développement.^[1] Aujourd'hui, on appelle ça une Internal Developer Platform. Un IDP construit sur Backstage.io comme couche catalogue, combiné à GitOps et à un portail self-service pour les environnements, n'est pas un jouet réservé aux GAFAM. C'est la seule réponse durable au goulot d'étranglement des capacités DevOps en ETI.

Pourquoi Adopt ? Les équipes de moins de huit développeurs backend ne peuvent pas s'offrir une équipe plateforme dédiée. En revanche, elles peuvent définir un Golden Path allégé : un template Dockerfile, un modèle CI/CD, un stack de monitoring. Ça suffit à réduire le temps d'onboarding de 40 %, un chiffre que nous avons mesuré en interne. Laisser aujourd'hui chaque développeur écrire son propre script de déploiement, c'est gaspiller de la séniorité.

Recommandation : Backstage.io pour démarrer, port.io comme alternative managée si vous n'avez pas de compétences Kubernetes en interne.

OpenTelemetry

L'observabilité sans vendor lock-in était une promesse jusqu'en 2022. Depuis OpenTelemetry v1.0 (Traces) et la stabilisation du signal Metrics, c'est une réalité. En 2026, le projet compte plus de contributeurs que tout autre projet CNCF, Kubernetes mis à part. OTEL est le seul standard défendable pour les Traces, Métriques et Logs dans toute nouvelle implémentation.

Sam Newman l'écrit dans Building Microservices (2ᵉ éd., 2022) : « L'observabilité n'est pas optionnelle dans un système distribué, c'est le prérequis de tout le reste. »^[2] Je le signe des deux mains. Quiconque reconstruit aujourd'hui avec des SDK Datadog ou des agents APM propriétaires échange une simplicité à court terme contre une dépendance à moyen terme. Au bout de 24 mois au plus tard, le coût de sortie dépasse l'avantage d'intégration.

Recommandation : OTEL Collector comme gateway centralisé. Le backend se choisit séparément (Grafana Tempo, Jaeger, ou solution commerciale), et c'est précisément l'intérêt du standard.

GitOps avec Flux v2 ou ArgoCD

Le déploiement comme état déclaratif dans le dépôt Git n'a rien d'une tendance passagère. C'est la conséquence logique de l'Immutable Infrastructure. Pratiquer l'Infrastructure-as-Code avec Terraform tout en déclenchant encore ses déploiements via kubectl apply ou Ansible, c'est trahir une rupture conceptuelle dans sa chaîne de delivery.

Flux v2 est le choix le plus conservateur : faible empreinte, CNCF graduated, modèle Pull sans connexion réseau entrante vers le cluster. L'avantage est net dans un contexte BSI. ArgoCD offre davantage d'UI et de support multi-cluster, au prix d'une plus grande complexité. Pour une ETI avec un seul cluster, ce sera Flux.

Recommandation : Flux v2 pour un cluster unique. ArgoCD à partir de trois clusters ou plus. Les décisions hybrides (les deux en même temps) relèvent de l'autopunition architecturale.

TRIAL: Lancer des pilotes ciblés, ne pas déployer à grande échelle

eBPF pour l'observabilité et la sécurité

Extended Berkeley Packet Filter est stable pour un usage en production depuis le kernel Linux 5.8. Ce que Cilium et Falco en tirent est substantiel : observabilité réseau transparente sans proxies sidecar, détection d'anomalies basée sur les syscalls sans installation d'agent par service. Dans le contexte des obligations de conformité NIS2 (délai de transposition d'octobre 2024 dépassé, et qui n'a pas encore agi est en retard), Falco/eBPF fournit un signal de détection d'intrusion qui complète les intégrations SIEM classiques.

Limitation : eBPF nécessite le contrôle du kernel. Dans les offres Kubernetes managées (AKS, GKE), c'est partiellement restreint. Sur Hetzner Dedicated et bare-metal propre, aucun obstacle.

Recommandation : Pilote avec Cilium comme CNI dans un cluster de staging. Décision après six mois d'expérience opérationnelle. Pas de déploiement généralisé sans référent eBPF interne.

Bases de données vectorielles pour les workloads RAG

Les grands modèles de langage sans connexion à la base de connaissances de l'entreprise sont largement inutiles dans un contexte B2B. Le Retrieval-Augmented Generation (RAG) est l'architecture pragmatique pour y remédier, et il réclame une base de données vectorielle. pgvector sur PostgreSQL suffit à la majorité des workloads ETI (moins de 10 millions de vecteurs, pas d'exigences sub-10ms). Pour des besoins plus exigeants, Qdrant est natif Rust, facile à déployer, compatible BSI puisqu'il s'auto-héberge.

Vlissides et al. formulaient en 1994 dans Design Patterns un principe qui tient toujours : « Programmer vers une interface, non vers une implémentation. »^[4] Il s'applique ici à la couche d'embedding. Assurez la compatibilité API avec OpenAI pour que le remplacement de modèle (Mistral local contre GPT-4o) reste possible sans refonte architecturale.

Recommandation : pgvector comme point de départ si PostgreSQL est déjà en place. Qdrant si une recherche vectorielle dédiée, avec filtrage sur des millions de documents, devient nécessaire. Pinecone ou Weaviate Cloud uniquement si la souveraineté des données n'est pas un enjeu, ce qui est rarement le cas en DACH.

Dagger.io pour des pipelines CI/CD portables

Les configurations CI sont devenues le nouveau vendor lock-in. YAML GitLab CI, syntaxe GitHub Actions, Groovy Jenkins : chaque chemin de migration coûte des mois. Dagger encapsule la logique de pipeline dans du code (Go, Python, TypeScript) et l'exécute à l'identique en local comme en cloud. La promesse « same pipeline everywhere » est tenue en 2026.

Limitation : Écosystème encore restreint, expérience de débogage en deçà des systèmes CI établis. Pas encore candidat Adopt, mais la direction est la bonne.

ASSESS: Observer, ne pas encore investir

Environnements de développement assistés par IA (Copilot, Cursor, Cody)

Les gains de productivité sur la complétion de code sont réels : GitHub a publié en 2023 une étude montrant 55 % de gain sur des tâches standardisées. La dette technique due au code généré et repris sans esprit critique l'est tout autant. Vaughn Vernon met en garde dans Implementing Domain-Driven Design (2013) contre l'« Anti-Pattern Smart UI », cette complexité qui atterrit dans la mauvaise couche.^[3] En l'absence de processus de revue, les assistants IA reproduisent ce schéma à l'échelle d'une codebase entière.

Position : Pertinent pour les développeurs juniors sous supervision senior. Pas un outil de productivité pour la modélisation de domaine complexe. Côté réglementaire : pour les projets qui touchent à des données personnelles, vérifiez la conformité RGPD des transferts (avec GitHub Copilot, les données quittent l'UE).

WebAssembly (WASM) hors du navigateur

WASM comme runtime côté serveur (via Spin, Wasmtime) promet une isolation sans overhead conteneur. Techniquement fascinant. Pour les workloads backend généraux, la maturité n'est pas encore au rendez-vous. À surveiller.

HOLD: Pas de nouveaux investissements

Jenkins comme plateforme CI/CD principale

Jenkins a une histoire glorieuse. Il a aussi un présent fait de cauchemars de maintenance : configuration XML, enfer de compatibilité des plugins, pas de modèle conteneur natif. En 2026, de meilleures alternatives existent (GitLab CI, GitHub Actions, Woodpecker CI pour le self-hosted) et fonctionnent toutes sans administrateur Jenkins dédié. La migration coûte du temps. Ne plus investir dans de nouveaux pipelines Jenkins coûte moins.

Exception : Infrastructure Jenkins existante et stable, avec une expertise fonctionnelle en place. Migration uniquement avec un déclencheur business clair.

Ansible comme seul outil IaC

Ansible est un excellent outil de gestion de configuration. Ce n'est pas un outil d'Infrastructure-as-Code au sens moderne : pas de state, pas d'étape Plan, pas de détection de drift. Provisionner des ressources cloud (Hetzner Cloud, Azure, AWS) via Ansible plutôt que Terraform ou OpenTofu, c'est construire sur un fondement conceptuel jamais pensé pour cette tâche.

Règle : Terraform/OpenTofu pour le provisionnement de l'infrastructure. Ansible pour la configuration OS et le déploiement applicatif sur l'infrastructure provisionnée. La combinaison est puissante. Utiliser chaque outil seul pour tout faire est un anti-pattern.

Déploiements monolithiques sans feature flags

Coupler les fonctionnalités directement aux releases, c'est coupler du même coup le risque business à chaque déploiement. Les feature flags (via Unleash, le standard OpenFeature, ou LaunchDarkly) découplent déploiement et release. Ce n'est pas une fonctionnalité de confort, c'est le prérequis au Trunk-Based Development et donc à la Continuous Delivery. Sans feature flags, pas de stratégie CI/CD cohérente.

Conclusion : Trois décisions pour le second semestre 2026

Si je devais donner une liste de priorités aux Tech Leads des ETI DACH, ce serait celle-ci.

1. Standardiser OpenTelemetry maintenant. Chaque nouveau service sans instrumentation OTEL est une dette technique à rembourser dans douze mois. L'effort aujourd'hui : deux jours. L'effort plus tard : deux semaines par service.

2. Introduire GitOps comme standard de déploiement. Non parce que ça sonne moderne, mais parce qu'auditabilité et rollback sans GitOps relèvent du travail manuel. Dans le contexte NIS2, ce n'est pas un nice-to-have.

3. Planifier la migration Jenkins. Pas de mise en œuvre immédiate, mais définissez un chemin de migration et arrêtez de construire de nouveaux pipelines dans Jenkins. La stratégie de conversion détermine les coûts de migration.

Le reste du radar donne une orientation. Ces trois points-là sont des décisions. Qui les reporte les prend quand même, dans de moins bonnes conditions.

Sources

[1] Martin Fowler, « Patterns of Enterprise Application Architecture », Addison-Wesley, 2002.

[2] Sam Newman, « Building Microservices », 2ᵉ éd., O'Reilly, 2022.

[3] Vaughn Vernon, « Implementing Domain-Driven Design », Addison-Wesley, 2013.

[4] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, « Design Patterns », Addison-Wesley, 1994.

[5] BSI IT-Grundschutz-Kompendium, Édition 2023.

[6] ThoughtWorks Technology Radar, vol. 30, avril 2024.