Roadmap Développeur · Édition 2026

La montée en compétences
du dev non-remplaçable

L’IA trie les bons des mauvais. Voici le plan concret pour faire partie de ceux qui restent — et qui prospèrent.

12 mois · 4 phases
Architecture · Patterns · Systèmes distribués
Par Pierre Legoux — Legoux du Web

« Ce qui ne se prompte pas, ça ne s’improvise pas non plus. »

Copilot et Claude génèrent du CRUD en secondes. C’est réel. La question n’est pas de savoir si l’IA remplace le code, elle l’est déjà en partie. La vraie question : qu’est-ce que l’IA ne peut pas faire seule ?

Elle ne peut pas concevoir une architecture qui tient à l’échelle. Elle ne détecte pas les erreurs logiques silencieuses dans un système legacy. Elle ne fait pas les bons arbitrages techniques sous contrainte business. Elle ne pense pas en systèmes.

Cette roadmap, c’est précisément ça. Un plan sur 12 mois pour construire les compétences que l’IA amplifie, plutôt que celles qu’elle remplace.

Ce que l’IA remplace
CRUD basique et boilerplate
Composants UI génériques
Scripts one-shot de 50 lignes
Documentation de code existant
Requêtes SQL simples
Tests unitaires sur du code évident

Ce que l’IA amplifie
Conception d’architectures systèmes
Revue critique du code généré
Détection des erreurs logiques
Arbitrages techniques complexes
Modélisation du domaine métier
Leadership et vision technique

PHASE 01

Fondations solides

Mois 1–3 · Environ 5h/semaine

Avant d’aller loin, tu dois savoir exactement où tu en es. Cette phase consolide les bases que tout le monde pense maîtriser, mais que peu appliquent vraiment.

Architecture

Les principes SOLID en pratique

Pas la théorie — l’application réelle sur du code de prod. SRP, OCP, LSP, ISP, DIP : un module par semaine, refactorisé depuis ton propre code.

  • Single Responsibility
  • Open/Closed
  • Dependency Injection
  • Interface Segregation
Algorithmique

Structures de données essentielles

Arrays, linked lists, hash maps, trees, graphs. Pas pour LeetCode — pour comprendre pourquoi PostgreSQL est plus rapide avec un index B-tree.

  • Big O notation
  • Hash maps
  • Trees & Graphs
  • Queues
Fondations

Git avancé & gestion de la dette

Branching strategies, rebase interactif, conventions de commit. Apprendre à lire un diff avec les yeux d’un senior.

  • Git flow
  • Conventional commits
  • Code review
  • Refactoring

OBJECTIF
À la fin de la phase 1, tu sais lire du code IA-généré et identifier immédiatement les violations de principes. Tu peux justifier chaque ligne que tu gardes ou supprimes.

PHASE 02

Design Patterns & DDD

Mois 3–6 · Environ 6h/semaine

Les patterns ne sont pas des templates à copier-coller. Ce sont des solutions éprouvées à des problèmes récurrents. Cette phase t’apprend à les reconnaître dans la nature et à les appliquer avec discernement.

Design Patterns

Patterns Créationnels

Factory, Abstract Factory, Builder, Singleton (et pourquoi l’éviter). Les patterns qui gouvernent la création d’objets — et donc 30% de ton architecture.

  • Factory Method
  • Builder pattern
  • Singleton
  • Prototype
Design Patterns

Patterns Structurels & Comportementaux

Adapter, Decorator, Observer, Strategy, Command. Ceux que tu utilises probablement déjà sans le savoir — apprends à les nommer et à les maîtriser.

  • Observer
  • Strategy
  • Decorator
  • Command
Domain-Driven Design

Modélisation du domaine métier

Ubiquitous Language, Bounded Contexts, Aggregates, Entities vs Value Objects. La compétence la plus rare : parler le même langage que le métier.

  • Bounded Contexts
  • Aggregates
  • Repositories
  • Domain Events
Architecture

Clean Architecture & Hexagonale

Ports & Adapters, séparation des couches, testabilité. Une architecture où changer de base de données ne touche pas à ta logique métier.

  • Use Cases
  • Ports/Adapters
  • Dependency Rule
  • Testing

OBJECTIF
Tu peux designer une feature de zéro sans jamais regarder un framework. Tu penses « domaine » avant de penser « technologie ». L’IA peut générer du code dans ton architecture — toi tu conçois l’architecture.

PHASE 03

Systèmes Distribués & Résilience

Mois 6–9 · Environ 7h/semaine

Là où la majorité des devs s’arrête. Et là où la pénurie de profils est la plus criante. Les systèmes distribués, c’est le monde réel — latence, pannes partiales, cohérence éventuelle.

Systèmes Distribués

Théorème CAP & cohérence

Consistency, Availability, Partition Tolerance : on ne peut pas avoir les trois. Comprendre ces arbitrages, c’est comprendre pourquoi Redis et PostgreSQL ne font pas le même boulot.

  • Théorème CAP
  • Eventual consistency
  • CRDT
  • Two-phase commit
Messagerie & Event-Driven

Architectures Event-Driven

Message queues, Event Sourcing, CQRS. Pourquoi les systèmes hautes perf ne font jamais d’appels synchrones en cascade. Kafka, RabbitMQ, la théorie derrière.

  • Event Sourcing
  • CQRS
  • Saga pattern
  • Outbox pattern
Résilience

Patterns de tolérance aux pannes

Circuit Breaker, Retry avec backoff exponentiel, Bulkhead, Rate limiting. Les systèmes qui tombent en 2024, c’est ceux qui n’ont pas ces patterns.

  • Circuit Breaker
  • Retry/Backoff
  • Bulkhead
  • Timeout
Observabilité

Monitoring, Tracing, Alerting

Les trois piliers : Metrics, Logs, Traces. OpenTelemetry, SLO/SLI/SLA. Un système que tu ne peux pas observer, tu ne peux pas le maintenir.

  • OpenTelemetry
  • Distributed tracing
  • SLO/SLI
  • Alerting

OBJECTIF
Tu peux designer une architecture microservices résiliente, expliquer les tradeoffs à un CTO, et détecter une race condition dans un système concurrent. Ces compétences ne s’apprennent pas avec Copilot.

PHASE 04

Leadership Technique & IA Augmentée

Mois 9–12 · Environ 6h/semaine

La phase finale transforme un bon dev en profil rare. Tu n’apprends plus seulement à coder — tu apprends à concevoir des systèmes, à valider ceux que l’IA produit, et à influencer techniquement.

IA-Augmented Dev

Prompt Engineering pour développeurs

Chain-of-thought, few-shot learning, RAG pipelines. L’IA n’est pas un outil, c’est un multiplicateur. Maîtriser ça, c’est faire 3x plus en solo.

  • Prompt patterns
  • RAG
  • Agentic flows
  • Code review IA
Architecture Decision

ADR & Documentation Technique

Architecture Decision Records, RFC process, Tech Radar. Savoir écrire une décision d’architecture qui convaincra ton équipe dans 6 mois — et l’IA dans 30 secondes.

  • ADR format
  • RFC process
  • Tech Radar
  • Tradeoff analysis
Performance

Optimisation systèmes end-to-end

Du SQL query plan au Critical Rendering Path — profiling, flamegraphs, cache strategy, database indexing avancé. La performance est une feature produit.

  • Query planning
  • Caching layers
  • Web Vitals
  • Profiling
Sécurité

Threat Modeling & Secure Design

OWASP Top 10, threat modeling STRIDE, defense in depth. Le code IA-généré n’est pas sécurisé par défaut. Quelqu’un doit savoir lire ce que personne ne lit.

  • OWASP Top 10
  • STRIDE
  • Zero Trust
  • Auth patterns

OBJECTIF
À 12 mois, tu es le dev qui valide ce que l’IA produit, qui conçoit ce qu’elle ne peut pas imaginer, et qui forme les autres. C’est ce profil que les boîtes cherchent et ne trouvent pas.

Ce qui ne se prompte pas

Les compétences transversales que l’IA ne peut pas acquérir à ta place — et qui font la différence en entretien et en prod.

Compétence Pourquoi c’est irremplaçable Niveau de rareté
Lecture de code legacy Comprendre ce que le code fait vraiment vs ce qu’il est censé faire. Pas de spec, pas de tests — juste du code. Élevé
Estimation réaliste Scoper une feature en tenant compte de la dette existante, des edge cases et du WTF factor. L’IA surestime systématiquement la vitesse. Très élevé
Debug systémique Isoler une panne dans un système distribué avec 12 microservices et des logs fragmentés. Un problème d’état sans stacktrace claire. Critique
Communication des tradeoffs Expliquer à un CPO pourquoi « faire vite » aujourd’hui coûte 6 mois dans 1 an. Et le convaincre avec des chiffres. Très élevé
Détection des erreurs silencieuses Le code tourne, les tests passent, la prod est en feu. Identifier la race condition ou la corruption de données avant qu’elle fasse des victimes. Critique
Vision produit technique Challenger un besoin. Proposer une solution qui apporte 80% de la valeur en 20% du temps. Savoir dire « cette feature n’a pas de sens ». Rare

Plan type d’une semaine

5h de pratique intentionnelle par semaine suffisent si elles sont bien réparties. La régularité bat l’intensité.

Lun
30 min théorie · Lire un chapitre / article ciblé

Mar
1h pratique · Implémenter un pattern sur un vrai projet

Mer
30 min review · Analyser du code open source

Jeu
1h pratique · Exercice algo ou archi sur Exercism / kata

Ven
30 min note · Écrire ce que tu as appris (blog, notion, tweets)

Sam
1h projet · Appliquer sur un side project ou client réel

Dim
Repos · Le cerveau consolide la nuit

// La semaine idéale = 4h30 de pratique · 1 chose apprise, 1 chose appliquée, 1 chose documentée

Bibliothèque de référence

Les livres qui m’ont changé la façon de penser l’architecture. Dans l’ordre où je les recommande.

Phase 1 · Architecture
Clean Code
Robert C. Martin
Le livre qui te fait réaliser que tu as écrit du mauvais code depuis le début. Douloureux, nécessaire.

Phase 1 · Algorithmique
Grokking Algorithms
Aditya Bhargava
La meilleure intro visuelle aux algos. Accessible, dense, illustré. Le seul livre d’algo que j’ai lu deux fois.

Phase 2 · Patterns
Design Patterns
Gang of Four
La bible. Dense. À lire avec un projet sous la main pour appliquer immédiatement chaque pattern.

Phase 2 · DDD
Domain-Driven Design
Eric Evans
Le livre qui change comment tu parles avec les clients. Lire la version abégée (DDD Distilled) d’abord.

Phase 3 · Systèmes
Designing Data-Intensive Applications
Martin Kleppmann
Le meilleur livre tech de la décennie. Couvre tout : réplication, partitioning, cohérence, streaming.

Phase 4 · Architecture
Clean Architecture
Robert C. Martin
La vision holistique de l’architecture logicielle. Découplage, testabilité, indépendance du framework.