module 04 / 06

Process équipe + IA

L'IA individuelle fait gagner des heures ; l'IA intégrée au process d'équipe fait gagner des semaines. Review assistée, PR workflow, conventions partagées — et les lignes rouges à ne jamais franchir.

4.0Objectifs de la session

Intégrer l'IA dans le PR workflow sans dégrader la qualité de review
Mettre en place une code review assistée (pré-review IA + décision humaine)
Définir des conventions d'usage IA partagées par toute l'équipe
Connaître les lignes rouges sécurité : secrets, code sensible, données clients

4.1Code review assistée

Le bon modèle mental : l'IA fait la pré-review, l'humain fait la review. L'IA passe en premier, dégrossit, signale ; le reviewer humain arrive sur une PR déjà nettoyée des problèmes évidents et concentre son attention sur ce qui compte vraiment.

Ce que l'IA attrape bien

Bugs évidents — null non géré, off-by-one, condition inversée, ressource non fermée
Style et cohérence — conventions de nommage, patterns du repo non respectés
Edge cases oubliés — chaîne vide, liste vide, concurrence, timezone
Incohérences mécaniques — doc qui ne correspond plus au code, type menteur

Ce qu'elle attrape mal

Contexte métier — « ce calcul de remise est faux pour les clients grands comptes »
Choix d'architecture — « cette abstraction va nous coûter cher dans 6 mois »
Historique d'équipe — « on a déjà essayé ça, ça a cassé la prod en mars »

Règle d'orL'IA signale, l'humain décide. Un commentaire de pré-review IA n'est jamais bloquant par lui-même : c'est un signal que le reviewer humain confirme ou écarte. La responsabilité du merge reste à 100 % humaine.

4.2PR workflow avec IA

L'IA excelle sur les tâches d'écriture autour du code : descriptions de PR, messages de commit, changelogs, ADR. Autant de friction en moins, à condition de garder des règles claires.

Descriptions de PR générées— l'IA résume le diff (quoi, pourquoi, comment tester) ; l'auteur relit et corrige. Une description générée non relue se voit immédiatement.
Commits atomiques — un commit = un changement logique. Les agents facilitent ça : demander explicitement des commits séparés par intention.
Doc auto— changelogs générés depuis les commits, ADR draftés par l'IA puis validés en revue d'archi. Le draft est IA, la décision est humaine.

Exemple de convention d'équipe

# .github/PULL_REQUEST_TEMPLATE.md — extrait

## Description
<!-- Générée par IA autorisée. Relue et corrigée par l'auteur : OBLIGATOIRE. -->

## Checklist auteur
- [ ] Pré-review IA exécutée, remarques traitées ou écartées avec justification
- [ ] Code sensible (auth / paiement / données perso) → 2e reviewer humain demandé
- [ ] Tests ajoutés ou mis à jour (générés par IA acceptés si relus)

4.3Conventions d'équipe : la charte IA

Sans règles explicites, chacun invente les siennes et l'équipe diverge. Une charte d'usage IA tient sur une page et répond à trois questions : qui utilise quoi, pour quoi faire, avec quels garde-fous.

Qui / quoi — outils autorisés (et versions/licences), qui a accès à quoi, qui paie
Mention IA dans les PR ou pas— décision d'équipe. Le plus courant : pas de mention obligatoire, mais l'auteur assume le code comme s'il l'avait écrit à la main
Propriété du code généré— le code mergé appartient à l'équipe ; « c'est l'IA qui l'a écrit » n'est jamais une excuse recevable
Revue obligatoire— aucun code généré ne part en prod sans lecture humaine, quelle que soit la confiance dans l'outil

Exemple de charte (une page, à adapter)1. Outils autorisés : Claude Code, Copilot (comptes entreprise uniquement).
2. Tout code généré est relu ligne à ligne par son auteur avant commit.
3. Aucun secret, aucune donnée client dans un prompt.
4. Code auth / paiement / crypto : double review humaine obligatoire.
5. L'auteur de la PR est responsable du code, quel qu'en soit le rédacteur.
6. Les décisions d'architecture se prennent en revue d'équipe, pas dans un chat IA.

4.4Sécurité : les lignes rouges

Cette section n'est pas négociable. Les règles suivantes protègent l'entreprise, les clients et l'équipe. Elles doivent être écrites dans la charte et connues de tous.

Lignes rouges — à ne jamais franchir1. Les secrets ne vont jamais dans un prompt.Clés d'API, tokens, mots de passe, chaînes de connexion : un prompt peut être journalisé, mis en cache ou utilisé pour l'entraînement selon l'outil et le contrat. Si un secret a fuité dans un prompt, il doit être révoqué et remplacé immédiatement, comme s'il avait été commité en clair.

2. Le code sensible exige une double review humaine. Authentification, cryptographie, paiement, gestion de permissions : l'IA produit du code plausible qui peut être subtilement faux (comparaison non constante, algorithme obsolète, contrôle d'accès incomplet). Deux humains relisent, dont un qui connaît le domaine.

3. Les données clients ne servent jamais d'exemple. Pour reproduire un bug ou illustrer un format, on anonymise ou on fabrique des données synthétiques. Une base de production ne se copie pas dans un chat, même partiellement.

4. La licence du code généré se vérifie. Un modèle peut restituer du code proche de sources sous licence restrictive. Pour tout bloc substantiel généré, un passage de vérification (recherche de similarité, outils de scan de licence) fait partie de la due diligence, en particulier pour du code redistribué.

Le réflexe à installer : avant d'envoyer un prompt, se demander « serais-je à l'aise si ce contenu apparaissait dans un log accessible à un tiers ? ». Si la réponse est non, on ne l'envoie pas.

4.5Quand NE PAS utiliser l'IA

Savoir s'abstenir fait partie de la maîtrise. Quatre situations où l'IA est le mauvais outil :

Décisions d'architecture engageantes— choix de base de données, découpage en services, contrats d'API publics. L'IA peut alimenter la réflexion, pas trancher : elle ne portera pas les conséquences pendant trois ans.
Code qu'on ne saurait pas relire— si personne dans l'équipe ne peut évaluer le code généré (domaine pointu, langage inconnu), le merger revient à signer un chèque en blanc.
Domaines où l'équipe doit apprendre— déléguer systématiquement, c'est renoncer à la compétence. Sur les sujets stratégiques pour l'équipe, on écrit d'abord à la main, on accélère avec l'IA ensuite.
Tâches plus rapides à la main— renommer une variable, corriger une typo, un one-liner évident. Écrire le prompt coûte plus cher que faire. L'IA est un levier, pas un réflexe.

4.6TP de la session

Dossier exercices/session-4/ du repo. Au programme :

TP1— Review assistée d'une PR piégée : bugs cachés à débusquer, comparer trouvaille IA vs trouvaille humaine
TP2— Atelier charte : rédiger la charte IA de l'équipe en sous-groupes, confronter, fusionner
TP3— Monter un pipeline de pré-review IA sur le repo d'exercices (déclenché à l'ouverture de PR)

4.7Checklist de fin de session

J'ai fait une pré-review IA sur une vraie PR et trié les remarques (confirmées / écartées)
Je sais citer les 4 lignes rouges sécurité sans regarder la page
J'ai contribué à un draft de charte IA avec mon sous-groupe
Je sais nommer 3 situations où l'IA est le mauvais outil
Le pipeline de pré-review du TP3 tourne sur le repo d'exercices

4.8Quiz de validation

Q1Dans une code review assistée, le rôle de l'IA est de…

Q2Une clé d'API a été collée dans un prompt par erreur. Que faire ?

Q3Une PR touche au module de paiement. La charte impose…

Q4Le but premier d'une charte IA d'équipe, c'est…

4.9Défi inter-session

D'ici la prochaine sessionProposer le draft de charte IA du TP2 à votre équipe réelle : le présenter en 15 minutes (réunion d'équipe ou fil dédié), recueillir les objections, noter ce qui passe et ce qui bloque. Retour d'expérience en ouverture de session 5.