Skip to content
PKResources
EN
Guides

Guide du leader technique pour bâtir un SDLC natif IA

Passer de développeurs qui utilisent chacun un assistant de code à un cycle de développement conçu où les agents participent à la planification, au code, à la revue, aux tests et aux ops.

par Patrick Kamtchueng Kom · Publié

La plupart des équipes ont « adopté l’IA » de la même façon : quelqu’un s’est fait rembourser un assistant de code, quelques personnes ont adoré, une politique est apparue six mois plus tard. Ce n’est pas un SDLC natif IA. C’est des individus avec une meilleure autocomplétion.

Un SDLC natif IA, c’est un cycle que vous avez conçu en considérant les agents comme des participants : ils reçoivent du travail, produisent des livrables, passent des contrôles et sont mesurés. C’est la différence entre « certains devs écrivent des tests » et « on a une CI ».

rédige les specs,découpe les ticketsdu ticket à laPR brouillonpremièrerevueajoute destestsrédige les notesde versionrésume lesincidentsPlanifierCoderRéviserTesterDéployerOpérercontrôle humain : mergecontrôle humain : déploiementles métriques décident de ce qu’on automatise ensuite
Où les agents se branchent dans le cycle, et où les humains gardent les contrôles.

Les stades de maturité

Cinq stades. Pas un bulletin, juste une façon d’être honnête sur où vous en êtes pour choisir la bonne prochaine étape.

  1. 0. ImproviséUsage perso du clavardage et de l'IDE. Aucune config, aucune politique. Responsable : personne.
  2. 1. EncadréOutils approuvés, politique de données, licences centralisées. Responsable : TI / sécurité.
  3. 2. ConventionsAGENTS.md, prompts partagés, règles de revue. Responsable : direction de l'ingénierie.
  4. 3. IntégréAgents lancés depuis les tickets, la revue, la CI, les incidents. Les humains tiennent les contrôles. Responsable : plateforme / DevEx.
  5. 4. Natif IATravail découpé pour les agents, contrôlé de bout en bout, métriques qui guident l'automatisation. Responsable : direction + plateforme.
Choisissez le stade visé par secteur : un service de paiement et un tableau de bord interne ne méritent pas la même autonomie.

📊 À quel point votre SDLC est-il natif IA?

  1. 1. On a un ou deux outils de code IA approuvés et une politique de données écrite.

  2. 2. Nos dépôts actifs contiennent des fichiers de contexte pour agents (AGENTS.md ou l'équivalent) avec un responsable.

  3. 3. On a des règles de revue convenues pour le code écrit par des agents, y compris une limite de taille des PR.

  4. 4. Les agents sont déclenchés par le flux de travail lui-même (tickets, CI, revue), pas seulement depuis l'éditeur de quelqu'un.

  5. 5. On a écrit quels types de travail les agents peuvent faire seuls et lesquels exigent un contrôle humain.

  6. 6. On a pris une baseline et on suit des métriques de flux et de qualité pour le travail impliquant des agents.

Répondez à toutes les questions pour voir votre résultat

Les décisions que vous seul pouvez prendre

Les enthousiastes vont volontiers choisir des outils et écrire des prompts. Les arbitrages ci-dessous, par contre, reviennent à la direction.

1. Le standard d’outillage

Un petit ensemble, choisi volontairement. La qualité des modèles change chaque trimestre; votre surface d’intégration, non. Revoyez le choix aux six mois, pas chaque semaine.

✕ À éviter

  • –Standardiser sur le meilleur outil du mois
  • –Juger les outils seulement sur les benchmarks
  • –Ne rien dire des outils non approuvés, et pousser les gens vers l'informel

✓ À faire

  • +Un outil agentique principal, sur lequel tout le monde est formé
  • +Une solution de rechange approuvée pour ses points faibles
  • +Outils non approuvés permis pour expérimenter sur du code non sensible, pas sur les dépôts de production
  • +Vérifier : fichiers d'instructions de dépôt, mode headless/CI, politique de données, contrôle des commandes, export d'usage

2. Les niveaux d’autonomie : où les agents agissent seuls et où les humains contrôlent

La décision la plus importante de ce guide. L’autonomie se définit par type de travail, pas par outil.

Niveau L’agent peut… L’humain… Bon usage
A. Suggérer Proposer du code dans l’éditeur Accepte ou rejette chaque changement Tout, par défaut
B. Rédiger Ouvrir une branche ou une PR brouillon Révise et assume le merge Fonctionnalités, correctifs, refactorings
C. Agir avec contrôle Aller de bout en bout, tests et PR inclus Approuve à un contrôle défini Mises à jour de dépendances, lint, ajout de tests, documentation
D. Agir et rapporter Exécuter et notifier Audite après coup Étiquettes de triage, brouillons de changelog, nettoyage de branches mortes

🎮 Autonome ou contrôlé par un humain?

1 / 9 · Pointage: 0

Où placeriez-vous chaque action d'agent, selon le tableau d'autonomie ci-dessus?

3. Le contexte et les conventions de dépôt

Un agent ne vaut que le contexte qu’il reçoit. Rendre chaque dépôt autodescriptif, c’est le geste le plus payant et le moins coûteux de ce guide.

🃏 Ce qu'on trouve dans un dépôt autodescriptif

Touchez une carte pour la retourner

Traitez ces fichiers comme du code : révisés, mis à jour quand le build change, et un fichier périmé est un bogue. J’ai vu des agents suivre des instructions de build en retard de deux migrations parce que personne n’était responsable du fichier.

4. La revue et les contrôles de qualité

Même exigence pour le code généré par IA. Ce qui change, c’est la façon de la tenir.

✕ Effondrement de la revue

  • –On révise le diff, pas l'intention
  • –Des PR d'agent de 2 000 lignes acceptées telles quelles
  • –Les approbations d'agent comptent dans les approbations requises
  • –« Les tests passent » pris dans la description de la PR
  • –Impossible de savoir quels changements viennent d'un agent

✓ Des contrôles sains

  • +Première question : est-ce le bon changement?
  • +Limite de taille souple, découpage exigé
  • +La revue d'agent est un filtre, jamais un contrôle
  • +Tests roulés en CI; modifications aux tests visibles en revue
  • +Étiquette de provenance, pour mesurer les résultats plus tard

5. La politique de sécurité et de données

Écrivez-la avant de passer à l’échelle, pas après le premier incident. La plupart de ces risques sont des erreurs de conception, pas des erreurs de modèle.

✅ Politique de sécurité et de données

0 / 6 complété

6. La mesure

Sans chiffres, ça devient « ça semble plus rapide » contre « ça semble plus risqué », et c’est le plus bruyant qui gagne. Mesurez le système, pas les individus.

Dimension Quoi suivre
Flux Délai du ticket à la production, temps de cycle des PR, attente de revue
Qualité Taux d’échec des changements, défauts échappés, retours arrière, incidents liés à des changements récents
Adoption Part des PR impliquant un agent, par dépôt et par type de travail
Coût Dépenses d’outils par ingénieur et par changement mergé
Expérience Court sondage trimestriel sur les frictions et la confiance

Prenez une baseline avant le pilote et comparez avec une équipe semblable. Deux chiffres que je refuse d’utiliser comme mesure de productivité : les lignes de code générées et le taux d’acceptation. Les deux récompensent le volume, que les agents produisent déjà en trop.

Un déploiement par phases : 90 jours

Une équipe pilote de quatre à huit personnes, et un responsable avec au moins une journée par semaine de temps protégé.

  1. 1

    Jours 0 à 30

    Fondations et projet pilote (atteindre le stade 2)

    Choisissez une équipe avec une bonne couverture de tests et un lead partant. Mesurez-la, ainsi qu'une équipe de comparaison. Décidez des outils, publiez la politique de données. Laissez un agent rédiger l'AGENTS.md, puis l'équipe le corrige. Tableau d'autonomie prudent (surtout A et B). Demi-journée pratique sur de vrais tickets. Rétro hebdo de 30 minutes.

  2. 2

    Jours 31 à 60

    Intégrer au flux de travail (stade 3 pour quelques flux)

    Branchez deux ou trois flux (ticket vers PR brouillon, première revue, ajout de tests) dans la CI ou la billetterie, au moindre privilège et en bac à sable. Ajoutez l'étiquette de provenance et une consigne de taille des PR. Montez un type de travail peu risqué au niveau C. Démarrez une bibliothèque de prompts partagée. Revoyez les métriques au jour 45 : si la qualité glisse, arrêtez d'étendre.

  3. 3

    Jours 61 à 90

    Étendre et institutionnaliser

    Documentez le pilote honnêtement, échecs compris. Emballez conventions, tableau d'autonomie, règles de revue, jobs de CI et formation d'accueil. Déployez dans deux ou trois équipes, chacune avec un parrain du pilote. Confiez la responsabilité à la plateforme ou au DevEx. Planifiez une revue trimestrielle.

Les modes d’échec courants

Tous évitables. Retournez chaque carte pour voir la correction.

🃏 Mode d'échec → correction

Touchez une carte pour la retourner

La liste de vérification

À passer en revue de direction à la fin de chaque phase. Votre progression est sauvegardée dans le navigateur.

✅ Revue de direction de fin de phase

0 / 6 complété

🧠 Petit test

Pointage: 0 / 4

  1. 1. Quel est le meilleur signe que vous êtes vraiment au stade 3?

  2. 2. Comment définir l'autonomie?

  3. 3. L'approbation d'un agent peut-elle compter dans les approbations requises?

  4. 4. Quelle métrique éviter comme mesure de productivité?

À faire cette semaine

✅ Cette semaine

0 / 5 complété