Votre agence écrit votre code avec l'IA. Voici ce qu'il faut exiger avant de signer

Oui, votre agence utilise presque certainement l'IA pour écrire une partie de votre code, et ce n'est pas un problème. Ce qui est un problème, c'est du code rédigé par l'IA qu'aucun humain n'a relu attentivement et qu'aucun test n'exerce, fusionné un vendredi parce que la démo était prévue. La solution n'est pas d'interdire l'outil. C'est une courte liste de garde-fous à inscrire dans le contrat et dans le repository avant le premier sprint.

Pourquoi c'est plus important qu'il y a deux ans

Un développeur équipé d'un assistant de code peut produire en un après-midi une fonctionnalité d'apparence fonctionnelle qui prenait auparavant trois jours. C'est bien réel. Le problème, c'est que la relecture, les tests et la compréhension n'ont pas progressé au même rythme. Si une agence conserve les mêmes habitudes de relecture qu'avant tout en triplant sa production, vous obtenez le même taux de bugs par ligne, appliqué à trois fois plus de lignes.

La dette technique s'accumulait autrefois à vitesse humaine. Elle s'accumule désormais à vitesse machine, et elle semble propre en surface. La première version de notre propre moteur de prospection, décrite à la section 4, était une chaîne en cinq étapes magnifiquement lisible : chaque étape bien nommée, chaque fonction commentée avec assurance, rien qui aurait arrêté un relecteur. Elle comportait aussi cinq endroits où échouer silencieusement, et c'est précisément cette propreté apparente qui expliquait que personne ne remettait en question les quatre étapes superflues. Le code écrit par l'IA est bien formaté et bien nommé, ce qui est précisément ce qui pousse un relecteur peu rigoureux à le survoler. Nous avons évoqué cette discipline générale dans la gestion de la dette technique. Cet article traite de la version spécifique qui apparaît lorsque c'est un prestataire qui écrit le code.

Les cinq choses à exiger

1. Un contrôle de tests qui bloque les fusions, pas une promesse de tests

« Nous écrivons des tests » est une phrase. Un contrôle (gate) est une configuration. Demandez ces deux éléments avant le début du travail :

• Une protection de branche sur main pour que rien ne soit fusionné tant que le pipeline est en échec. GitHub documente cela sous branches protégées, et chaque hébergeur majeur propose un équivalent.
• Un seuil de couverture appliqué dans la CI, pas rapporté dans une présentation. Sur une stack TypeScript, cela représente quelques lignes dans une configuration Vitest ou Jest. Le chiffre importe moins que le fait qu'il fasse échouer le build quand il baisse.

Posez ensuite une question qui distingue les agences : « Pouvez-vous me montrer une pull request du mois dernier qui a été bloquée par un test en échec ? » Si la réponse est « nos tests ne tombent jamais en échec », c'est qu'ils ne testent rien.

2. Un humain nommé qui lit chaque diff rédigé par l'IA

Les assistants produisent du code. Ils n'en assument pas la responsabilité. Votre contrat doit nommer qui le fait, et le repo doit le prouver : chaque pull request a un relecteur qui n'est pas l'auteur, et la relecture comporte des commentaires, pas seulement une coche verte.

Méfiez-vous de deux anti-patterns :

• Les pull requests auto-fusionnées. Une personne prompte, la même personne approuve. C'est une relecture nulle.
• La relecture par IA uniquement. Les bots de relecture IA repèrent le style et les bugs évidents. Ils ne savent pas que votre règle de tarification comporte une exception de TVA pour les clients saoudiens. L'humain qui connaît le métier doit lire le diff.

3. Une politique de dépendances et de secrets

Les assistants IA adorent ajouter des packages. Ils iront chercher une bibliothèque pour un simple formatage de chaîne. Chaque ajout est une surface d'attaque de la chaîne d'approvisionnement et une question de licence. Exigez :

• Un lockfile versionné et une règle imposant que toute nouvelle dépendance soit signalée dans la description de la pull request.
• Aucun secret, aucune donnée client ni code propriétaire collé dans des outils qui s'entraînent sur les données saisies. La plupart des offres entreprise des principaux assistants proposent un paramètre de non-entraînement ; le contrat doit préciser que l'agence en utilise un.
• Une attribution claire de tous les livrables à vous, quelle que soit la manière dont ils ont été produits. Les bonnes agences le font déjà. La clause IA ferme simplement l'échappatoire du « mais c'est un outil qui l'a écrit ».

4. Moins de lignes, pas plus

Le code le moins coûteux à tester est celui qui n'a jamais été écrit. L'IA rend indolore la génération d'un pipeline en six étapes là où une seule suffirait, et chaque étape supplémentaire est un endroit où une défaillance silencieuse peut se produire.

Nous avons vécu cela avec notre propre moteur de prospection. Il scrape le site d'un prospect avec un crawler auto-hébergé et utilise un modèle local pour rédiger un e-mail personnalisé par entreprise. La première version était une chaîne : extraire les faits, résumer, choisir un angle, rédiger, peaufiner. C'était plus lent, plus coûteux, et surtout, cela comportait cinq endroits susceptibles de dysfonctionner et cinq éléments à tester. En la ramenant à un seul appel qui extrait les faits et rédige en une passe, nous avons battu la chaîne à la fois en coût et en qualité du résultat, tout en réduisant de moitié la surface à couvrir par les tests. Nous avons détaillé le cas général dans appel unique vs chaînes d'agents.

Demandez à votre agence comment elle décide quand du code généré est devenu trop volumineux. Si elle n'a pas de réponse, vous paierez les lignes superflues deux fois : une fois pour les écrire, une fois pour les maintenir.

5. Une base de code que vous pourriez confier à quelqu'un d'autre

Le véritable test du code écrit par l'IA, c'est de savoir si un nouvel ingénieur, avec ou sans assistant, peut le lire en une semaine. Exigez :

• Des décisions d'architecture consignées dans le repo, dans un court dossier de documentation ou un fichier ADR, pas dans un historique de chat. Notez le pourquoi, pas seulement le quoi. Si votre agence ramène une chaîne en cinq étapes à un seul appel, comme nous l'avons fait, la raison doit figurer à côté du code, sinon le prochain ingénieur équipé d'un assistant reconstruira la chaîne, car une chaîne est précisément ce vers quoi les assistants tendent naturellement.
• Des patterns cohérents entre les fonctionnalités. Les assistants IA dérivent. La fonctionnalité A utilise un style d'accès aux données, la fonctionnalité B un autre, parce qu'elles ont été promptées à des jours différents. Le linting et un petit ensemble de modèles (templates) corrigent l'essentiel de ce problème.
• Des tests d'intégration pour les flux qui génèrent votre chiffre d'affaires : l'inscription, le paiement, le webhook de votre prestataire de paiement. Les tests unitaires sur des fonctions utilitaires sont un remplissage peu coûteux. L'exception de TVA saoudienne de la section 2 est précisément le type de règle que seul un test de bout en bout sur un véritable paiement détectera, et couvrir ainsi les trois parcours avec un outil comme Playwright protège votre chiffre d'affaires.

Ce que cela change pour le devis

Attendez-vous à ce que les devis honnêtes baissent sur le travail répétitif : écrans CRUD, formulaires, tables d'administration, intégrations standards. Attendez-vous à ce qu'ils restent globalement stables sur les parties qui n'ont jamais été limitées par la vitesse de frappe : le modèle de données, les cas particuliers de vos règles métier, la performance, et la relecture elle-même.

Une agence dont le devis a baissé de 60 % sur l'ensemble depuis l'adoption des outils IA a soit réduit la relecture, soit est sur le point de le faire. Une agence dont le devis n'a pas bougé du tout ne répercute probablement pas les économies réalisées. Le juste milieu honnête consiste en un chiffre plus bas sur le travail prévisible et un poste dédié aux tests et à la relecture qui n'a pas diminué. Si vous hésitez entre différents modèles d'engagement, prix fixe vs temps et matériaux détaille comment structurer cela.

Questions à poser lors du premier appel

• Quels outils de code IA utilisez-vous, et sur quelle offre tarifaire ?
• Montrez-moi votre protection de branche et votre configuration CI sur un projet récent.
• Qui relit le code rédigé par l'IA, et puis-je voir une pull request avec de vrais commentaires de relecture ?
• Comment décidez-vous quand du code généré devient trop volumineux ?
• Que deviennent mon code et mes données à l'intérieur des outils que vous utilisez ?

Des réponses claires et précises signifient que l'agence a réfléchi à la question. Une réassurance vague signifie que vous êtes le premier client à la poser. Associez ces questions aux signaux d'alerte des projets logiciels plus généraux, et vous écarterez l'essentiel du risque en une seule conversation.

En résumé

Les outils de code IA sont un multiplicateur de vitesse. Multipliez une équipe rigoureuse et vous obtenez une équipe rigoureuse qui livre plus vite. Multipliez une équipe négligente et vous obtenez de la négligence à grande échelle, avec une base de code qui semble excellente jusqu'au premier incident réel. Votre rôle d'acheteur n'est pas de choisir l'outil. C'est d'exiger le contrôle, le relecteur, la politique et le repo lisible, puis de vérifier qu'ils existent bien.

Si vous voulez un développement où les tests sont dans le pipeline et le relecteur nommé avant le premier commit, parlons-en.