Aller au contenu
SwankyForge
SwankyForge
Toutes les analyses
Article10 min de lecture

Avec une IA en binôme dans chaque dépôt, nous automatisons les contrôles et gardons cinq décisions humaines

Comment l'équipe d'ingénierie travaille avec les assistants de code IA : ce qui s'exécute automatiquement à chaque changement, ce qu'une personne décide toujours, et ce que nous n'avons pas encore mesuré.

L'essentiel du travail d'ingénierie dans nos dépôts commence désormais par un premier jet écrit par un assistant de code IA. Rien n'est livré sur la seule parole de l'assistant. Cette note décrit le dispositif tel qu'il existe dans le dépôt derrière ce site web, parce que c'est celui que nous pouvons montrer publiquement. Elle liste aussi les décisions que nous laissons aux personnes, et le chiffre que nous ne pouvons pas encore vous donner.

La version courte, si vous achetez

Nous sommes un petit laboratoire de deux ingénieurs, avec des spécialistes ajoutés selon les projets. Un assistant IA travaille aux côtés de chacun de nous deux. Il rédige les premiers jets de code, de tests, de documentation et de comptes rendus courants. Des contrôles automatisés s'exécutent à chaque changement et bloquent ceux qui enfreignent une règle. Une personne lit chaque changement avant qu'il ne soit fusionné. Rien n'atteint la production ni le public sans un « oui » explicite.

Ce que vous y gagnez : les deux mêmes ingénieurs couvrent une plus grande part du travail courant que les petites équipes ont tendance à sauter, comme les tests, la documentation et les contrôles de mise en production. Cela laisse une plus grande part du budget aux parties qui demandent du jugement : choisir la métrique, décider si un modèle vaut la peine d'être construit, et l'intégrer à votre processus.

Ce que nous ne prétendons pas : un chiffre de gain de vitesse. Nous n'en avons pas mesuré, et les données externes disent que les gains de vitesse déclarés ne sont pas fiables. Les dernières sections disent ce que nous mesurerions et ce que cela signifie pour un client.

Ce que dit la recherche : l'outil n'est pas le gain

Quatre études de 2025 ont orienté la manière dont nous avons mis cela en place.

  • Le programme DORA de Google a interrogé près de 5 000 professionnels de la tech pour son rapport 2025. 90 % utilisent l'IA au travail, et plus de 80 % pensent qu'elle les a rendus plus productifs. Pourtant, 30 % font peu ou pas confiance au code qu'elle génère. La synthèse du rapport est que l'IA « amplifie ce qui est déjà là » : les équipes solides s'améliorent, les équipes en difficulté voient leurs problèmes s'aggraver.
  • Le Technology Report 2025 de Bain a constaté que les équipes qui utilisent des assistants de code IA gagnent 10–15 % de productivité. Certaines entreprises annoncent 25–30 %, mais seulement quand l'IA s'accompagne d'une refonte de tout le processus. Une raison pour laquelle le premier chiffre est faible : écrire et tester le code représente environ 25–35 % du temps entre l'idée et le lancement.
  • Le Stack Overflow Developer Survey 2025 a montré que 84 % des répondants utilisent ou prévoient d'utiliser des outils IA, et que 46 % se méfient de l'exactitude des résultats. La frustration la plus courante était un résultat presque juste, mais pas tout à fait.
  • METR a mené un essai randomisé avec 16 développeurs open source expérimentés sur 246 tâches réelles. Quand les outils IA étaient autorisés, les tâches prenaient 19 % de temps en plus. Les développeurs s'attendaient à un gain de 24 %, et pensaient encore après coup avoir été 20 % plus rapides. Les auteurs préviennent que le résultat est propre à leur contexte : de grands projets open source matures et des développeurs ayant une expérience limitée de l'outil utilisé.

Lues ensemble, les études disent trois choses. Adopter un assistant est facile. Le gain dépend du processus qui l'entoure. Et l'impression de quiconque sur sa propre vitesse n'est pas une preuve. Nous avons donc mis l'effort dans le processus (instructions, contrôles et points d'approbation) plutôt que dans le choix de l'outil.

Ce que fait l'assistant dans notre dépôt

Nous utilisons Claude Code. Cinq éléments rendent son travail prévisible.

Les instructions de projet. Un fichier à la racine du dépôt indique à l'assistant ce qui se trouve où, quelles règles sont strictes et quelles commandes exécuter. Il est versionné comme du code, si bien qu'une modification des règles apparaît en revue comme n'importe quel autre changement. Toute personne ayant accès au dépôt peut lire exactement ce qui a été dit à l'assistant.

Des skills pour les tâches récurrentes. Un skill est une courte procédure écrite que l'assistant suit pour un type de tâche. Nous en avons huit : rédiger une étude de cas avec son dossier de preuve, rédiger une note d'ingénierie, rédiger un post pour la page de l'entreprise, générer un profil pour une plateforme externe, vérifier un texte à la recherche de noms confidentiels et de données personnelles, un audit en lecture seule des signaux de confiance du site, un rapport d'avancement hebdomadaire, et le tri des demandes entrantes. Chaque skill indique où il s'arrête. Aucun ne se termine par la publication de quoi que ce soit.

Les hooks. Les actions de l'assistant passent par des scripts que nous avons écrits. Après qu'il a modifié un fichier, ce fichier est analysé à la recherche de noms confidentiels et de données personnelles, et toute détection renvoie l'assistant corriger. Avant qu'il puisse exécuter un git commit ou un push, une garde lance l'analyse de confidentialité et le lint des affirmations sur ce qui s'apprête à quitter l'arbre de travail. Toute détection bloque la commande. Un simple hook git pre-commit applique les mêmes contrôles aux commits faits à la main.

La CI à chaque push et pull request. Le pipeline exécute le lint, la vérification des types et un build, puis trois gardes :

  • l'analyse de confidentialité, sur le code source, le contenu et le HTML rendu. Si sa configuration est absente, elle échoue au lieu de passer silencieusement ;
  • le lint des affirmations, qui rejette une liste de superlatifs et de formules d'autorité empruntée ;
  • le validateur de contenu, qui refuse une étude de cas sans dossier de preuve, une architecture de référence qui revendique des chiffres mesurés, et un chiffre de la page d'accueil qui ne renvoie pas à l'étude de cas dont il provient.

Ces règles sont mécaniques à dessein. Un assistant produit vite du texte plausible, et le plausible-mais-faux est exactement l'échec que décrivent les enquêtes. Une règle qui s'exécute à chaque commit ne dépend de la vigilance de personne, humain ou modèle.

Le pipeline de contenu. Tout ce qui est destiné au public passe par trois dossiers : brouillons, approuvé, publié. Un skill peut écrire dans les brouillons et nulle part ailleurs. Seul le propriétaire exécute l'étape d'approbation, qui relance les deux analyses avant de déplacer le fichier. La publication est manuelle : un post approuvé est envoyé au propriétaire sous forme de texte prêt à coller, et une note approuvée ne passe en ligne qu'avec le prochain push approuvé vers main. Cette note a suivi ce chemin. Un assistant l'a rédigée à partir des propres fichiers du dépôt, les analyses ont tourné dessus, et elle est arrivée sur cette page après qu'une personne l'a approuvée.

Ce que nous ne déléguons jamais

Cinq décisions restent aux personnes, quoi que puissent faire les outils.

  1. Fixer la métrique avec le client. Quel chiffre définit le succès, comment il est mesuré et quel seuil vaut achèvement. Nous l'inscrivons au contrat avant le début de l'entraînement. Un assistant peut lister des métriques candidates. Il ne peut pas savoir sur laquelle votre entreprise agira.
  2. Juger si le ML en vaut la peine. Parfois, la réponse honnête est une règle, un rapport ou un changement de processus. « Ne faites pas encore de ML » est une recommandation que nous formulons, et c'est un jugement sur votre situation, pas une tâche de génération de texte.
  3. Approuver les mises en production. Une fusion dans main déploie. Rien n'est poussé vers main sans un « oui » explicite du propriétaire, et les permissions de l'assistant excluent le force-push.
  4. Parler au client. Appels, réponses écrites, mauvaises nouvelles. Un skill peut rédiger un brouillon de réponse à une demande ; une personne le lit, le modifie et l'envoie. Aucun script ne contacte un prospect.
  5. Décider de ce qui devient public. Posts, notes, profils, études de cas et publications de code. Le pipeline fait de la publication une étape délibérée plutôt qu'un comportement par défaut.

Le fil conducteur est la responsabilité. Chacune de ces décisions a des conséquences dont quelqu'un doit répondre, et ce quelqu'un doit être une personne. Sur un projet, c'est l'ingénieur nommé qui reste sur le travail du début à la fin.

Ce que nous n'avons pas mesuré

Nous n'avons pas de chiffre avant/après pour notre propre productivité, et nous n'en citerons pas. Le résultat de METR en est la raison : des développeurs 19 % plus lents pensaient être 20 % plus rapides. Une impression, la nôtre comprise, n'est pas une mesure.

Si nous publions un chiffre, il portera le même label de preuve que nos études de cas (mesuré, estimé ou illustratif), et il proviendra d'enregistrements comme ceux-ci, collectés sur une fenêtre précisée :

  • le délai entre l'ouverture d'un ticket et un changement relu et fusionné, pour des types de tâches comparables ;
  • la part des changements fusionnés annulés ou corrigés dans les 14 jours ;
  • les problèmes détectés par les hooks et la CI avant fusion, comparés aux défauts trouvés après ;
  • le temps de revue par changement, parce que c'est en revue que la production d'un assistant coûte du temps aux personnes ;
  • les heures par jalon comparées à l'estimation de notre calculateur.

D'ici là, l'affirmation honnête est plus étroite. Les contrôles s'exécutent à chaque changement, et les cinq décisions ci-dessus sont prises par des personnes.

Ce que cela signifie pour vous

Une plus grande part du travail courant est faite. À budget fixe, les tests, la documentation, le monitoring et les contrôles de mise en production sont ce que les petites équipes coupent en premier. Un assistant les rend moins coûteux à écrire, et les contrôles les rendent difficiles à sauter.

Le prix va au jugement. Nos tarifs et les heures derrière chaque rôle sont publiés sur la page des tarifs, et le calculateur montre le calcul. Les heures qui comptent le plus sont celles passées sur la métrique, l'évaluation et l'intégration à votre processus : les parties qu'aucun assistant ne fait à notre place. Si vous n'êtes pas sûr que le ML soit la bonne réponse, le teardown gratuit donne un premier verdict en six questions, et un court cadrage payant tranche la question avant qu'aucun modèle ne soit entraîné.

Vous pouvez inspecter le dispositif. Le dépôt vit dans votre organisation dès le premier jour. Si un assistant y travaille, ses instructions et ses contrôles se trouvent aussi dans ce dépôt, à côté de l'historique de chaque changement, là où vous pouvez les lire.

Posez les mêmes questions à chaque prestataire. Quels outils IA verront votre code et vos données, et à quelles conditions ? Quels contrôles s'exécutent à chaque changement, et bloquent-ils ou se contentent-ils d'avertir ? Qui approuve une mise en production ? Le prestataire a-t-il mesuré son propre gain de vitesse, et comment ? Les réponses vous disent si l'IA dans son processus amplifie la discipline ou son absence.

Sources

Un processus vous coûte trop cher ?

Parlez-nous-en. Le premier appel est gratuit, et si l'IA n'est pas la réponse, nous le disons.

Discuter de votre tâche