- Angular 22 : skills IA pour coder avec des agents

Angular 22 (juin 2026) et le virage IA

Angular v22 est sorti le 3 juin 2026, et cette version marque un tournant autant technique que culturel. Sur le plan technique, elle stabilise les Signal Forms, bascule la détection de changement en OnPush par défaut, adopte l'API Fetch comme backend par défaut du HttpClient, introduit le décorateur @Service et rend stable le package @angular/aria. Mais la nouveauté la plus stratégique est ailleurs : Angular s'adresse désormais explicitement aux agents IA.

Concrètement, l'équipe Angular fournit des « skills » : des instructions structurées qui apprennent à un agent IA à réaliser des tâches précises dans un contexte Angular, afin qu'il produise du code idiomatique. Ce n'est pas une fonctionnalité du runtime, mais un actif de connaissance destiné à guider ChatGPT, Claude, GitHub Copilot ou Gemini quand ils écrivent du code pour votre projet.

Pourquoi ce virage ? Parce que la majorité des développeurs utilisent aujourd'hui un assistant IA au quotidien, et que ces assistants ont un défaut connu : ils ont été entraînés sur des années de code Angular, incluant des styles dépassés (NgModule, décorateurs @Input() historiques, *ngIf). Sans guidage, un agent produit souvent du code « moyen » représentatif de tout Internet, pas du code aligné sur la dernière version. Les skills corrigent ce biais en injectant le contexte le plus récent au moment de la génération.

Il faut rester lucide : ces skills sont une aide au développement assisté par IA, pas une garantie. Ils augmentent la probabilité d'obtenir du bon code, mais la revue humaine, la compilation et les tests restent indispensables. Tout au long de cet article, nous garderons ce cadre prudent.

Qu'est-ce qu'un « skill » pour un agent de code ?

Un skill est un ensemble d'instructions contextuelles, généralement rédigées en Markdown, qui décrivent à un agent IA comment réaliser une catégorie de tâches. Là où un prompt brut est une demande ponctuelle et volatile, un skill est une connaissance procédurale réutilisable : il encapsule le contexte, les conventions, les exemples idiomatiques et les pièges à éviter.

La différence est fondamentale. Comparons une demande adressée à un agent avec et sans skill.

# Prompt brut (sans skill)
« Crée-moi un composant Angular pour afficher une liste d'utilisateurs. »

# Résultat probable : code hétérogène, potentiellement daté
# - peut utiliser NgModule au lieu de standalone
# - peut utiliser *ngFor au lieu de @for
# - peut oublier OnPush et les Signals

Avec un skill « génération de composant Angular » chargé, l'agent dispose du même prompt mais aussi d'une feuille de route : composant standalone, contrôle de flux @for/@if, état via signal(), entrées via input(), stratégie OnPush implicite en v22. Le résultat devient prévisible et conforme.

<!-- Extrait d'un skill Markdown : conventions de composant -->
## Génération de composant

Toujours produire un composant `standalone` (pas de NgModule).
Utiliser le nouveau contrôle de flux : `@for`, `@if`, `@switch`.
Déclarer l'état réactif avec `signal()` et les entrées avec `input()`.
Ne jamais utiliser `*ngFor`, `*ngIf`, ni `@Input()` décorateur historique.

### Exemple idiomatique attendu
```ts
@Component({
  selector: 'app-user-list',
  standalone: true,
  template: `
    @for (user of users(); track user.id) {
      <li>{{ user.name }}</li>
    }
  `,
})
export class UserListComponent {
  users = input.required<User[]>();
}
```

On voit ici la nature d'un skill : il ne fait pas le travail à la place de l'agent, il oriente son travail. Il agit comme une documentation opérationnelle que l'agent consulte au moment de générer, ce qui le distingue nettement d'un simple prompt.

Les skills officiels fournis par l'équipe Angular

Avec Angular 22, l'équipe Angular met à disposition des skills officiels couvrant les tâches les plus courantes du quotidien d'un développeur. L'idée est de fournir une base fiable, maintenue par les auteurs du framework eux-mêmes, plutôt que de laisser chaque développeur réinventer ses propres consignes.

Parmi les grands domaines couverts, on retrouve typiquement :

• Génération de composants : composants standalone, contrôle de flux moderne, entrées/sorties basées Signals.
• Migrations : accompagner le passage d'anciens patterns vers les nouveaux (par exemple d'un état basé sur des propriétés vers des Signals).
• Bonnes pratiques Signals : usage correct de signal(), computed(), effect(), et pièges de réactivité à éviter.
• Formulaires : orientation vers les Signal Forms stabilisés en v22.
• Détection de changement : cohérence avec le mode OnPush désormais par défaut.

Un skill officiel « bonnes pratiques Signals » ressemble, dans l'esprit, à un guide de style exécutable. Voici un extrait illustratif de ce que peut contenir un tel skill.

# Skill (illustratif) : bonnes pratiques Signals

## À faire
- Dériver les valeurs calculées avec `computed()`, jamais recalculer à la main.
- Garder les `effect()` pour les effets de bord (log, sync DOM), pas pour dériver de l'état.
- Exposer l'état en lecture seule via `signal.asReadonly()` depuis un service.

## À éviter
- Muter un signal dans un `computed()` (interdit : lecture pure uniquement).
- Créer un `effect()` qui écrit dans le signal qu'il lit (boucle).

Et le code idiomatique que l'agent est censé produire en s'appuyant sur ce skill :

// Service d'état idiomatique guidé par le skill Signals
import { Injectable, signal, computed } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class CartStore {
  // État privé mutable
  private readonly _items = signal<CartItem[]>([]);

  // Exposition en lecture seule
  readonly items = this._items.asReadonly();

  // Valeur dérivée : jamais recalculée manuellement
  readonly total = computed(() =>
    this._items().reduce((sum, i) => sum + i.price * i.qty, 0)
  );

  addItem(item: CartItem): void {
    // Mise à jour immuable du signal
    this._items.update(list => [...list, item]);
  }
}

Attention toutefois : au moment où vous lisez ces lignes, la surface exacte des skills officiels et leur mode de distribution peuvent évoluer. Considérez la liste ci-dessus comme représentative des domaines couverts plutôt que comme un inventaire figé. Référez-vous toujours à la documentation Angular officielle pour la liste à jour.

Le Angular CLI MCP Server et sa complémentarité

Les skills ne sortent pas de nulle part : ils s'inscrivent dans une stratégie plus large, dont le Angular CLI MCP Server est l'autre pilier. MCP (Model Context Protocol) est un standard qui permet à un agent IA de communiquer avec des outils externes et d'accéder à des données en temps réel. Le serveur MCP du CLI Angular expose ainsi votre projet à l'agent.

La distinction est essentielle et souvent mal comprise :

• Le MCP Server fournit des capacités d'action et des données live : version exacte du projet, schematics disponibles, exécution de commandes, documentation contextuelle. C'est le « bras » et les « yeux » de l'agent sur votre code réel.
• Les skills fournissent la connaissance procédurale : comment réaliser une tâche correctement. C'est le « savoir-faire » de l'agent.

Autrement dit, le MCP répond à « quel est l'état du projet et quels outils puis-je invoquer ? », tandis que le skill répond à « comment dois-je écrire ce code pour qu'il soit idiomatique ? ». Un agent réellement performant combine les deux.

Le démarrage d'un serveur MCP côté CLI s'appuie sur une commande du type ci-dessous. Traitez-la comme un exemple illustratif : vérifiez la syntaxe exacte dans la documentation de votre version d'Angular CLI.

# Exemple type — démarrer le serveur MCP du CLI Angular
# (syntaxe illustrative, à confirmer selon votre version)
ng mcp

# L'agent se connecte ensuite au serveur pour interroger le projet :
# - version d'Angular installée
# - liste des schematics
# - documentation contextuelle des API

Installer et utiliser les skills avec un agent

La manière d'installer un skill dépend de l'agent que vous utilisez, car chaque écosystème (Claude, GitHub Copilot, Gemini) a ses propres conventions de fichiers d'instructions. Le principe reste le même : rendre le contenu du skill accessible à l'agent au moment où il génère du code dans votre projet.

Dans la pratique, cela passe souvent par un fichier d'instructions déposé à la racine du dépôt ou dans un dossier dédié. Voici des emplacements typiques selon l'agent — considérez-les comme des exemples représentatifs plutôt que comme des chemins normatifs.

# Emplacements typiques de fichiers d'instructions selon l'agent
# (exemples représentatifs — vérifiez la doc de votre agent)

# GitHub Copilot
.github/copilot-instructions.md

# Claude (Claude Code)
CLAUDE.md
.claude/skills/angular/SKILL.md

# Gemini / autres
GEMINI.md  ou  .ai/instructions.md

Une fois le skill en place, l'usage devient conversationnel. Vous formulez une demande métier, et l'agent applique en arrière-plan les conventions du skill. Comparez les deux prompts suivants : le second n'a pas besoin de répéter les règles, car le skill s'en charge.

# Sans skill : vous devez tout préciser à la main
« Crée un composant standalone Angular, sans NgModule,
  avec @for et track, l'état en signal(), les entrées en
  input.required(), et pense à OnPush. Affiche une liste de tâches. »

# Avec skill chargé : la demande reste métier
« Crée un composant qui affiche une liste de tâches
  avec un bouton pour marquer chaque tâche comme terminée. »

Le second prompt est non seulement plus court, mais aussi plus fiable, car les conventions ne dépendent plus de votre mémoire ni de votre formulation. Voici le type de composant qu'un agent correctement guidé produit à partir de la demande courte.

// Résultat attendu avec un skill Angular v22 actif
import { Component, signal, input } from '@angular/core';

interface Task {
  id: number;
  label: string;
  done: boolean;
}

@Component({
  selector: 'app-task-list',
  standalone: true,
  template: `
    <ul>
      @for (task of tasks(); track task.id) {
        <li>
          <span [class.done]="task.done">{{ task.label }}</span>
          <button (click)="toggle(task.id)">Terminer</button>
        </li>
      } @empty {
        <li>Aucune tâche.</li>
      }
    </ul>
  `,
})
export class TaskListComponent {
  // Entrée requise typée (pas de décorateur @Input historique)
  readonly initialTasks = input.required<Task[]>();

  // État local réactif
  readonly tasks = signal<Task[]>([]);

  toggle(id: number): void {
    this.tasks.update(list =>
      list.map(t => (t.id === id ? { ...t, done: !t.done } : t))
    );
  }
}

Enfin, rappelez-vous que charger un skill ne dispense jamais de vérifier le résultat. Après chaque génération, compilez, lancez le lint, exécutez les tests. Le skill augmente le taux de réussite ; il ne remplace pas votre pipeline de qualité.

Écrire son propre skill Angular pour son équipe

Les skills officiels couvrent le framework, mais chaque équipe a ses conventions maison : structure de dossiers, nommage des services, gestion d'état préférée, règles de sécurité. Écrire un skill interne permet d'imposer ces standards à tous les agents utilisés dans le projet, de façon cohérente.

Un bon skill maison suit une structure simple et lisible. Il énonce le contexte, liste les règles positives (« à faire »), les règles négatives (« à éviter »), et fournit des exemples concrets — idéalement un exemple idiomatique et un contre-exemple. Voici un squelette réutilisable.

# Skill maison — Conventions Angular de l'équipe

## Contexte
Projet Angular 22, standalone, état via Signals, SSR activé.

## Structure de dossiers
- `features/<domaine>/` : composants et logique métier par domaine
- `core/` : services transverses (auth, http, config)
- `shared/` : composants et pipes réutilisables sans état

## Conventions de code
- Un composant = un dossier (`ts`, `html`, `css`, `spec`).
- Nommer les services `XxxStore` quand ils portent de l'état Signal.
- Toute entrée de composant : `input()` / `input.required()`.
- Toute injection : fonction `inject()`, jamais le constructeur.

## Garde-fous de sécurité
- Ne jamais interpoler d'HTML brut sans `DomSanitizer`.
- Ne jamais logguer de token ni de donnée personnelle.
- Toute requête HTTP passe par le service `core/http`, jamais `HttpClient` direct.

## À éviter absolument
- `any` non justifié, `NgModule`, `*ngIf`/`*ngFor`, `subscribe()` sans cleanup.

La force d'un skill maison tient à ses exemples. Fournir un contre-exemple explicite est souvent plus efficace qu'une règle abstraite, car l'agent voit précisément le pattern à ne pas reproduire.

# Extrait de skill : injection de dépendances

## À faire (idiomatique)
```ts
export class UserService {
  private readonly http = inject(HttpClient);
}
```

## À éviter (déconseillé par l'équipe)
```ts
export class UserService {
  // Injection par constructeur : proscrite dans ce projet
  constructor(private http: HttpClient) {}
}
```

Pensez aussi aux garde-fous. Un skill n'est pas qu'un guide de style : c'est un endroit idéal pour encoder des règles de sécurité et de conformité. Interdire les logs de données sensibles, forcer le passage par une couche HTTP centralisée, imposer la sanitization : autant de contraintes que l'agent respectera si elles sont écrites noir sur blanc.

Bonnes pratiques : contexte, revue, tests, limites

Adopter les skills sans discipline peut donner une fausse impression de sécurité. Voici les pratiques qui séparent une utilisation professionnelle d'un usage naïf du développement assisté par IA.

1. Fournir le bon contexte, mais pas trop

Un agent submergé d'instructions contradictoires ou trop volumineuses perd en précision. Le principe du contexte minimal suffisant s'applique : donnez au skill ce qui est nécessaire pour la tâche, pas l'intégralité de votre documentation interne. Un skill focalisé bat un skill encyclopédique.

2. Toujours passer par la revue humaine

Le code généré doit être lu, compris et validé par un humain avant tout merge. Un agent peut produire du code qui compile mais qui contient une faille logique, une régression subtile ou un problème de sécurité. La revue n'est pas optionnelle : c'est la ligne de défense principale.

# Boucle de validation minimale après chaque génération IA
ng build            # le code compile-t-il ?
ng lint             # respecte-t-il les règles de style ?
ng test             # les tests passent-ils ?
# + revue humaine du diff avant merge

3. Exiger et vérifier les tests générés

Un skill peut demander à l'agent de produire les tests en même temps que le code. C'est une excellente pratique, à condition de ne pas faire confiance aveuglément : un test généré par le même agent qui a écrit le code peut valider un comportement erroné. Relisez les assertions, vérifiez qu'elles testent le bon contrat.

// Test généré : à relire avec esprit critique
it('bascule l\'état terminé d\'une tâche', () => {
  const fixture = TestBed.createComponent(TaskListComponent);
  const cmp = fixture.componentInstance;
  cmp.tasks.set([{ id: 1, label: 'A', done: false }]);

  cmp.toggle(1);

  // Vérifier que l'assertion teste le VRAI contrat métier
  expect(cmp.tasks()[0].done).toBe(true);
});

4. Connaître les limites : hallucinations

Même guidé par un skill, un agent peut halluciner : inventer une API qui n'existe pas, importer un symbole imaginaire, ou combiner deux versions incompatibles. Le skill réduit ce risque en ancrant l'agent dans les conventions réelles, mais ne l'élimine pas. Méfiez-vous particulièrement des API « trop belles pour être vraies ».

5. Documenter ce qui a été généré

Pour la maintenabilité et la traçabilité, il est sain de savoir quelles parties du code ont été produites avec assistance IA, surtout dans les zones sensibles. Cela facilite les audits ultérieurs et aide l'équipe à cibler les revues.

L'avenir du développement Angular assisté par IA

La démarche d'Angular 22 — livrer des skills officiels et un serveur MCP — dessine une tendance de fond : les frameworks ne s'adressent plus uniquement aux humains, mais aussi aux agents qui écrivent du code aux côtés des humains. On peut raisonnablement anticiper que les prochaines versions enrichiront cette couche : plus de skills, mieux intégrés aux outils, et couvrant des tâches de plus en plus larges (refactoring, migrations complètes, audits).

Ce mouvement ne signifie pas la fin du développeur. Il déplace la valeur : moins de temps passé à écrire du code répétitif, plus de temps consacré à l'architecture, à la revue critique, à la définition des conventions (donc à l'écriture des skills eux-mêmes) et à la validation. Le développeur qui maîtrise ces outils devient un chef d'orchestre plutôt qu'un simple exécutant.

Trois évolutions probables méritent d'être surveillées :

• Standardisation : convergence des formats de skills entre agents, pour éviter de dupliquer les instructions par outil.
• Skills contextuels dynamiques : des skills capables de s'adapter en lisant le projet réel via MCP, plutôt que des instructions statiques.
• Validation intégrée : des boucles où l'agent compile et teste automatiquement son propre code avant de le proposer, réduisant les allers-retours.

Mais quelle que soit la maturité de ces outils, un invariant demeure : la responsabilité du code reste humaine. Les skills et le MCP sont des amplificateurs de productivité, pas des remplaçants du jugement. Les équipes qui réussiront seront celles qui investissent autant dans leurs conventions et leur revue que dans l'outillage IA.

Checklist d'adoption des skills IA en équipe

Conclusion. Angular 22 ne se contente pas d'améliorer le framework : il reconnaît que le code s'écrit désormais à quatre mains, humain et agent. Les skills officiels et le serveur MCP donnent aux agents le contexte et le savoir-faire pour produire du code Angular idiomatique, tandis que vos skills maison y ajoutent vos standards. Mais l'outil ne dispense jamais du jugement : revue humaine, tests et vigilance restent la clé. Adoptez ces skills comme un accélérateur discipliné, et vous gagnerez en vélocité sans sacrifier la qualité.