Former une équipe technique à l'IA sur ses vrais tickets

Les équipes techniques n’ont pas besoin qu’on leur explique ce qu’est un assistant de code. La plupart en ont déjà essayé un, souvent plusieurs. Ce qui leur manque, c’est le passage de l’essai ponctuel à une pratique intégrée au flux de travail — sans que la qualité du code en fasse les frais.

Nous avons déjà écrit ce qui marche, et ce qui n’est que du théâtre, quand on forme des équipes à l’IA. Cet article porte sur le cas particulier des développeurs, et sur une conviction : on forme une équipe technique sur ses vrais tickets, dans ses vrais outils, ou on ne la forme pas.

Pourquoi la formation en salle s’évapore#

Une salle, un vidéoprojecteur, un dépôt de démonstration créé pour l’occasion. L’exercice fonctionne, tout le monde suit, la journée se passe bien.

Le lundi suivant, l’ingénieur retrouve sa base de code : des années d’historique, des conventions que personne n’a écrites, une chaîne d’intégration continue capricieuse, des tickets dont le contexte est dispersé entre Jira, la merge request et la mémoire d’un collègue. Rien de ce qu’il a vu ne ressemble à ça.

Le vrai savoir-faire avec un assistant de code n’est pas de formuler une demande. C’est de lui donner le bon contexte : les règles du projet, les fichiers concernés, l’intention du ticket, ce qu’il ne doit surtout pas toucher. Ce contexte n’existe que dans les outils de l’équipe. Un exercice propre l’efface, et avec lui la seule partie difficile.

Ce que change le travail sur les vrais outils#

Travailler sur les tickets en cours change trois choses.

Le point d’entrée et le point de sortie sont réels. Le ticket Jira dit ce qu’il faut faire, la merge request GitLab est l’endroit où le résultat sera jugé. Entre les deux, l’assistant n’est qu’un outil de plus, soumis aux mêmes règles que les autres.

Chacun travaille sur son poste, avec ses accès. Ce qui fonctionne pendant la formation fonctionne le lendemain, sans dépendre d’un environnement de démonstration qui part avec le formateur. Et les blocages apparaissent tout de suite : un droit manquant, un jeton d’accès à créer, un outil interne mal documenté. Autant les régler ensemble que les découvrir seul trois semaines plus tard.

Les conventions s’écrivent. Un assistant de code ne devine pas les règles d’une équipe : il faut les lui donner. Claude Code, par exemple, lit à chaque session un fichier CLAUDE.md placé dans le dépôt, que la documentation officielle présente comme le lieu des commandes de build et de test, des standards de code et des décisions d’architecture, partagé avec l’équipe par le contrôle de version. Rédiger ce fichier ensemble oblige à formuler des règles qui n’existaient que dans les têtes — un bénéfice qui dépasse largement l’IA.

Le cas Stellar : deux jours, aucune diapositive#

En septembre 2026, nous avons passé deux jours sur site, dans la région bordelaise, chez Stellar, qui assure une connectivité continue en combinant réseaux cellulaires et satellitaires avec son logiciel STEER®. Nous avons travaillé avec deux ingénieurs de l’équipe STEER®.

Pas de diapositives. Chacun sur son poste, avec ses accès Jira et GitLab, sur des cas réels et en cours. Trois objectifs : de meilleures pratiques avec les assistants de code, des flux de travail automatisés là où une tâche répétitive mobilisait un ingénieur, et un modèle d’IA local pour réduire la consommation de jetons sur les tâches volumineuses comme la revue de code et les tests. Nous avons installé n8n et Ollama en auto-hébergé sur une machine du laboratoire de test.

Un exemple de ce qui en est sorti : un flux de revue automatisée, utilisé sur une merge request de 99 fichiers. Claude Code déclenche un workflow n8n — lui-même construit avec Claude —, qui s’appuie sur un modèle Qwen 3.6 exécuté en local. Le résultat arrive dans GitLab en dix minutes. L’ingénieur garde la décision finale. Selon l’équipe, c’est « probablement près d’une demi-journée » de travail fastidieux évitée. Matthieu Sevestre, CPTO de Stellar, a raconté ces deux jours sur LinkedIn.

Ce type de résultat ne sort pas d’un exercice de salle. Il suppose une vraie merge request, une vraie forge et une vraie machine sur laquelle faire tourner le modèle.

Comment cadrer deux jours#

Deux jours, c’est court. Ce qui fait la différence se prépare avant.

En amont, l’équipe choisit quelques tickets en cours, de nature variée : une évolution, une correction, une revue lourde, une tâche répétitive qui agace tout le monde. On vérifie les accès de chacun aux outils. Si un modèle local est envisagé, on identifie la machine qui l’hébergera et on s’assure qu’elle est disponible.

Le premier jour porte sur les pratiques. On traite les tickets choisis avec l’assistant, on écrit les conventions du projet au fur et à mesure, et on regarde ensemble où l’outil se trompe. C’est là que se forme le jugement : savoir quand déléguer, quand reprendre la main, quoi relire ligne à ligne.

Le second jour porte sur l’automatisation. On prend la tâche répétitive la plus coûteuse et on la transforme en flux de bout en bout, branché sur les outils existants, utilisé au moins une fois sur un cas réel avant de partir.

Le livrable n’est pas un support de cours. C’est un flux qui tourne, des conventions écrites, et une équipe qui sait comment le premier a été construit.

Garder les standards d’ingénierie#

C’est la crainte la plus fréquente, et elle est fondée : un assistant de code mal encadré produit vite du code que personne ne comprend vraiment. Trois règles suffisent à la neutraliser.

• Aucune voie de contournement. Ce que produit l’IA passe par la même merge request, la même revue et la même intégration continue que le reste. Il n’existe pas de circuit parallèle.
• L’humain décide. Une revue automatisée signale, classe, résume ; elle n’approuve pas. Chez Stellar, l’ingénieur garde la décision finale et sait simplement où concentrer son attention.
• On ne fusionne pas ce qu’on ne sait pas expliquer. Si l’auteur de la merge request ne peut pas justifier une modification devant un collègue, elle n’entre pas, quel que soit l’outil qui l’a écrite.

Ces règles ne sont pas propres à l’IA. Ce sont celles d’une équipe qui travaille bien. L’IA oblige simplement à les rendre explicites.

Ce qui reste quand le formateur est parti#

Une formation se juge à ce qui tourne encore un mois plus tard. Sur des exercices de salle, la réponse est presque toujours : rien. Sur les tickets de l’équipe, il reste au minimum un flux en service, un fichier de conventions que l’assistant relit à chaque session, et surtout des ingénieurs qui savent construire le flux suivant sans aide.

C’est le principe de notre formation IA pour équipes techniques : se déplacer chez vous, travailler dans vos outils, et partir en laissant quelque chose qui fonctionne.