L’IA ne remplace pas les développeurs : elle amplifie leurs bonnes et mauvaises pratiques

L’arrivée de l’IA dans le développement logiciel ne se résume pas à écrire du code plus vite. Elle transforme la manière dont les développeurs explorent une codebase, résolvent des tickets, documentent leurs changements et valident ce qu’ils livrent.

Son intérêt réel ne se mesure donc pas uniquement en temps gagné. Il se mesure aussi à la capacité d’une équipe à cadrer, relire et valider ce qu’elle produit avec l’IA.

C’est là que le sujet devient intéressant : l’IA augmente réellement le développeur, mais elle augmente aussi les conséquences de ses méthodes de travail. Quand les tickets sont clairs, les objectifs bien formulés et les validations bien organisées, elle devient un levier puissant. Quand les demandes sont floues ou les responsabilités de validation implicites, elle peut accélérer la production de dette technique avec une efficacité redoutable.

L’extension de périmètre, bénéfice immédiat

Le gain le plus immédiat de l’IA au quotidien n’est pas seulement la vitesse. C’est l’extension du périmètre d’action.

Exemple concret : un ticket signale une erreur d’affichage dans un document généré côté backend. La cause est une logique de calcul de date qui ne prend pas en compte un cas métier précis : un statut dépend de deux événements distincts dans le temps, mais ces événements sont mal combinés dans la requête. Le projet tourne sur une stack que le développeur assigné, plutôt orienté front, ne maîtrise pas totalement — même s’il connaît le projet et son métier.

Sans IA, ce ticket aurait probablement attendu le bon expert. Avec l’IA, le développeur peut avancer : décrire la règle métier, partager les fichiers concernés, demander une analyse de la logique existante, puis identifier précisément l’endroit où le calcul déraille. Le diagnostic est posé rapidement, la correction est ciblée, le ticket est résolu.

Second cas, plus radical : un ticket front sur un projet que le développeur n’a jamais touché, dont il ne connaît ni le métier ni la structure. Une notification pointe vers un contenu supprimé côté back-office : l’utilisateur arrive sur une erreur sans message explicatif. La correction implique trois éléments à coordonner : afficher un message d’erreur lisible côté front, supprimer la notification orpheline en base, et décrémenter correctement le compteur affiché dans l’interface.

Ces trois points auraient facilement pu être traités séparément, avec le risque d’en oublier un. L’IA a permis d’identifier rapidement le code concerné dans une codebase inconnue, de proposer une implémentation cohérente sur les deux couches — front et API — et de ne pas passer à côté du détail du compteur. Ce qui aurait pu prendre une journée d’exploration s’est réglé en quelques heures.

Ces deux cas illustrent une logique plus large. Comprendre la structure d’un projet, ses règles métier implicites et ses conventions demande habituellement plusieurs itérations avec l’équipe. L’IA réduit fortement ce temps de montée en contexte.

L’extension de périmètre dépasse d’ailleurs le seul développement applicatif. Avec les bons accès et les bons garde-fous, elle peut aussi aider à interroger une base de données pour vérifier un comportement suspect, inspecter des logs serveur pour isoler une erreur, ou automatiser des tâches répétitives qui auraient autrement mobilisé un temps disproportionné.

Ce n’est pas anodin. Cela signifie qu’une équipe peut traiter un backlog plus varié, affecter les tickets avec plus de souplesse, et réduire certaines dépendances aux expertises individuelles. Sur le papier, c’est à la fois un gain de productivité et un gain d’organisation.

Mais ce gain a une contrepartie : plus le périmètre d’action s’élargit, plus la validation doit être structurée.

L’empreinte de l’IA dans l’historique Git

L’historique d’un développeur qui intègre l’IA dans son quotidien change de forme.

Les commits deviennent souvent plus larges. Là où un développeur aurait naturellement découpé son travail en plusieurs petites modifications successives, l’IA traite fréquemment plusieurs aspects d’un problème dans une même réponse. Un commit peut alors toucher simultanément plusieurs fichiers, mêler une correction de logique métier, une mise à jour de la couche de données et un ajustement d’affichage.

Sur la documentation, le constat est presque inverse. Un développeur expérimenté va souvent à l’essentiel dans ses messages de commit. L’IA, elle, prend généralement le temps de détailler les changements, leur justification et parfois les points d’attention associés.

Git rend donc visible une asymétrie nouvelle : des commits plus denses, mais mieux expliqués.

Cette évolution n’est pas neutre. Un commit plus documenté n’est pas nécessairement un commit plus maîtrisable. Lorsqu’un même changement touche la logique métier, la persistance et l’interface, la revue doit être adaptée : découpage logique, description des hypothèses, identification des points sensibles, et validation par une personne capable d’évaluer le périmètre fonctionnel.

Autrement dit, l’IA améliore souvent la lisibilité déclarative du changement, mais elle ne garantit pas sa lisibilité technique ou métier.

Cela pose une question de méthode : faut-il accepter des commits plus gros parce qu’ils sont mieux documentés ? Pas nécessairement. La bonne pratique consiste plutôt à ne pas laisser le découpage du commit refléter passivement la réponse de l’IA. Le découpage doit rester piloté par l’humain : une intention fonctionnelle, un périmètre cohérent, une revue possible.

Pour une équipe, cela peut se traduire par quelques règles simples :

• séparer les changements par intention fonctionnelle plutôt que par séquence de génération ;
• expliciter dans le message de commit les hypothèses prises par l’IA ;
• signaler les zones qui nécessitent une validation métier ;
• éviter les commits multi-couches lorsqu’ils rendent la revue trop coûteuse ;
• renforcer la revue humaine dès qu’un changement touche plusieurs parties du système.

Git ne ment pas. Il enregistre le rythme, la taille et l’intention déclarée de chaque modification. Avec l’IA, il devient aussi un indicateur de gouvernance : il montre si l’équipe garde la maîtrise de ce qu’elle livre, ou si elle laisse l’outil structurer le travail à sa place.

L’angle mort : savoir ce qu’on valide

L’extension de périmètre que permet l’IA est réelle. Mais elle introduit une responsabilité nouvelle : savoir précisément ce que l’on est en mesure de valider.

Le premier cas a bien fonctionné parce que le développeur maîtrisait suffisamment le métier pour évaluer la correction proposée. Il pouvait lire le diff, comprendre la logique de filtrage par date, confirmer que la correction couvrait le problème en profondeur — et pas seulement le cas visible.

C’est cette capacité de jugement, combinée à l’IA, qui produit un résultat solide.

Le risque n’est pas seulement que l’IA produise du mauvais code. Le risque est qu’elle produise une correction techniquement plausible, qui semble correcte en revue rapide, mais qui ne couvre pas tous les cas métier. Dans ce scénario, personne ne voit l’erreur immédiatement : le code compile, les tests passent peut-être, l’interface semble fonctionner. Pourtant, une hypothèse importante a pu rester implicite.

Ce n’est pas une question de compétence individuelle. C’est un problème structurel. Plus le périmètre d’action s’étend, plus les responsabilités de validation doivent être explicites.

La question n’est donc pas : « l’IA a-t-elle bien fait le travail ? »

La bonne question est : « qui est en mesure de valider ce qu’elle a produit, et à quelle étape ? »

Intégrer l’IA dans un workflow d’équipe, c’est répondre clairement à cette question. Il faut distinguer plusieurs niveaux de validation :

• validation technique : le code est-il cohérent avec l’architecture, maintenable, testé, sécurisé ?
• validation fonctionnelle : le comportement répond-il réellement au besoin exprimé ?
• validation métier : les règles implicites, les cas limites et les impacts opérationnels sont-ils bien couverts ?
• validation de périmètre : le changement ne modifie-t-il pas plus que ce qui était prévu ?

C’est à ce niveau que l’IA cesse d’être seulement un outil individuel. Elle devient un sujet d’organisation.

La qualité de l’input conditionne tout

L’IA ne comble pas un ticket mal écrit. Elle l’exécute — et amplifie son imprécision.

Le ticket évoqué plus haut en est un bon exemple : il était précis. Il donnait des cas concrets, identifiait la condition exacte qui posait problème, et distinguait explicitement l’erreur d’affichage du calcul sous-jacent qui, lui, était correct. Cette précision a rendu possible un diagnostic rapide et une correction ciblée.

Un ticket formulé « la colonne est parfois fausse, à corriger » aurait produit une exploration beaucoup plus hasardeuse — et probablement un correctif partiel.

Donner un ticket tel quel à l’IA revient à espérer qu’elle interprétera les ambiguïtés dans le bon sens. Elle peut le faire. Mais elle ne le fera pas toujours. Et lorsque le développeur ne maîtrise pas suffisamment le périmètre pour évaluer le résultat, une mauvaise interprétation peut passer inaperçue jusqu’en production.

Les pratiques qui changent la donne sont simples, mais exigent une discipline active.

Reformuler avant de soumettre

Si le ticket est flou, il faut le reformuler jusqu’à ce qu’il soit précis — pas seulement pour l’IA, mais pour soi. Comprendre ce qu’on demande avant de le déléguer reste une condition de qualité.

Annoncer l’objectif global avant de lancer le développement

Pour les tâches complexes, il est préférable de décrire d’abord l’objectif final, de demander un plan, d’évaluer sa pertinence, puis d’itérer. Lancer l’IA directement dans le code sur un ticket ambigu revient à démarrer un sprint sans avoir cadré la user story.

Décomposer les tickets complexes

« Nous allons d’abord faire X, pour ensuite faire Y, l’objectif final étant Z. » Cette structure donne à l’IA le contexte nécessaire pour arbitrer correctement, au lieu de traiter chaque sous-tâche comme un problème isolé.

Rendre explicites les contraintes non négociables

Certaines règles doivent être posées dès le départ : conventions de nommage, périmètre interdit, compatibilité à préserver, règles métier sensibles, tests attendus, dépendances à ne pas introduire.

Une bonne demande à l’IA n’est donc pas seulement une instruction. C’est un mini-cadrage de développement.

L’IA comme dernier regard avant de livrer

Une pratique simple produit régulièrement de bons résultats : une fois le développement terminé, soumettre le code à l’IA et lui demander si elle y voit des incohérences, des oublis ou des risques potentiels.

Pas pour valider le fond métier. Pas pour remplacer une revue de code humaine. Mais pour détecter ce qui peut passer entre les mailles : un cas limite non géré, une variable mal initialisée, une condition trop restrictive, une incohérence de nommage, un test manquant, une hypothèse implicite à vérifier.

Régulièrement, cette relecture fait émerger un point utile. Parfois mineur, parfois plus significatif. Dans tous les cas, elle oblige le développeur à prendre un recul supplémentaire sur ce qu’il s’apprête à livrer.

Cette pratique fonctionne bien à condition d’être cadrée. Il ne s’agit pas de demander à l’IA : « est-ce que c’est bon ? » La question est trop vague. Il faut l’orienter :

• quels cas limites ne sont pas couverts ?
• quelles hypothèses semblent implicites ?
• ce changement peut-il avoir un effet de bord ?
• le découpage du code reste-t-il cohérent ?
• quels tests devraient être ajoutés ou complétés ?
• quelles parties nécessitent une validation humaine ou métier ?

L’IA devient alors un relecteur complémentaire. Elle ne décide pas si le livrable est acceptable. Elle aide à mieux préparer cette décision.

Le risque de fragmentation sur les features longues

Un autre angle mort apparaît sur les features qui s’étendent sur plusieurs tickets : la fragmentation.

L’IA n’a pas naturellement de mémoire fiable entre les sessions. Deux tickets liés à la même feature, traités à quelques jours d’intervalle, peuvent produire deux implémentations indépendantes — légèrement divergentes dans leurs conventions, leurs structures de données ou leurs nommages.

Individuellement, chaque morceau peut être correct. Collectivement, l’ensemble devient incohérent.

Ce n’est pas théorique. C’est précisément ce qui arrive quand on oublie de forcer la continuité : des endpoints qui ne se parlent pas tout à fait, des états gérés en double, des petites variations entre tickets qui semblaient anodines et qui deviennent problématiques dès qu’on relie les morceaux.

La correction est simple, mais elle doit être systématique : à chaque nouveau ticket d’une même feature, il faut redonner explicitement le contexte de ce qui a déjà été produit, rappeler les conventions établies et imposer la cohérence comme contrainte.

L’IA ne maintiendra pas cette cohérence d’elle-même. Elle doit être pilotée.

Pour les features longues, la bonne pratique consiste à maintenir un court document de contexte partagé :

• objectif global de la feature ;
• décisions techniques déjà prises ;
• conventions de nommage ;
• endpoints ou composants concernés ;
• contraintes métier ;
• points non négociables ;
• arbitrages déjà effectués.

Ce document peut ensuite être réinjecté à chaque nouvelle session IA. Il évite de repartir de zéro, réduit les divergences et rend la collaboration plus fiable.

Quand la complexité technique prend le dessus

L’IA n’est pas également efficace sur tous les tickets.

Sur des sujets bien délimités — un bug d’affichage, une règle métier à corriger, une gestion d’erreur à ajouter — elle produit rapidement des résultats exploitables. Sur des tickets qui combinent plusieurs problématiques techniques imbriquées, le rapport change.

Un ticket de cartographie hors-ligne en est un bon exemple : affichage de points d’intérêt via Leaflet et StadiaMaps, mise en cache des tuiles pour un fonctionnement sans connexion, calcul du nombre de tuiles à télécharger pour couvrir les points pertinents, filtrage des points trop excentrés pour ne pas surcharger le cache.

Chaque problématique prise isolément est accessible. Combinées, elles forment un système où chaque correction peut en déstabiliser une autre.

Autrement dit, le problème n’est plus seulement de produire un morceau de code. Il s’agit de maintenir la cohérence d’un système composé de plusieurs contraintes interdépendantes : performance, stockage, expérience utilisateur, fonctionnement hors-ligne, consommation réseau et pertinence métier des données affichées.

Sur ce type de ticket, même avec des prompts détaillés et précis, les itérations se multiplient. L’IA propose une solution qui règle un aspect et en dégrade un autre. Il faut reformuler, recontextualiser, tester, recommencer.

L’outil reste utile. Il structure la réflexion, propose des pistes, génère du code de base, aide à explorer des alternatives. Mais il ne remplace pas la capacité du développeur à tenir l’ensemble du problème en tête et à arbitrer entre les contraintes.

C’est une limite réelle, et utile à connaître : plus un ticket est transverse et interdépendant, plus le pilotage humain devient déterminant.

Ce que ce retour change pour une équipe

Les enseignements de ce retour d’expérience ne s’arrêtent pas au développeur individuel.

Le premier effet est immédiat : l’IA réduit certaines dépendances entre développeurs au quotidien. Une question sur une partie du code que l’on ne connaît pas, un bug dans une stack que l’on maîtrise mal, une compétence que l’on n’a pas encore : autant de situations où il fallait attendre qu’un collègue soit disponible. Aujourd’hui, on peut souvent se débloquer seul, avancer, puis n’impliquer l’autre que lorsque c’est réellement nécessaire.

Ce n’est pas un remplacement de la collaboration. C’est une réduction des frictions qui la rendaient parfois coûteuse.

Mais pour que ce gain soit durable, l’équipe doit adapter ses pratiques.

Pour une équipe produit ou startup : l’IA permet d’élargir le périmètre de chaque développeur, mais elle crée aussi un risque de dette silencieuse si les pratiques de relecture ne suivent pas. Le critère de merge ne peut plus se limiter à « ça passe en CI ». Il doit aussi intégrer la qualité du cadrage, la lisibilité des hypothèses et la validation du périmètre métier.

Pour une DSI : la traçabilité de l’usage IA devient un enjeu de gouvernance. Qui a produit quoi, dans quel contexte, avec quelle validation ? Git en garde une trace partielle, à condition que les conventions de commit, de revue et de documentation permettent réellement de comprendre les changements.

Pour une agence ou une ESN : industrialiser les pratiques IA sur plusieurs projets clients exige des règles partagées sur la qualité des inputs, la décomposition des tickets, les critères de validation et les responsabilités de revue. Ce qui fonctionne bien pour un développeur seul dans un contexte maîtrisé ne se généralise pas automatiquement.

Une grille simple peut aider à transformer ces constats en pratiques opérationnelles :

L’enjeu n’est donc pas seulement d’autoriser ou non l’usage de l’IA. L’enjeu est de définir les pratiques qui permettent d’en tirer parti sans perdre le contrôle sur la qualité livrée.

Conclusion

L’IA ne rend pas automatiquement un développeur plus compétent. Elle amplifie ses pratiques existantes.

Quand les tickets sont clairs, les objectifs bien formulés, les changements relus et les responsabilités de validation explicites, elle permet de gagner du temps, d’explorer plus vite une codebase et d’élargir réellement le périmètre d’action des équipes.

À l’inverse, lorsqu’elle est utilisée sur des demandes floues, sans cadrage ni revue adaptée, elle accélère la production de dette technique avec une efficacité redoutable.

Le sujet n’est donc pas seulement de savoir si une équipe utilise l’IA. Le vrai sujet est de savoir si elle sait organiser la qualité autour de cette nouvelle manière de produire.

C’est précisément là que Castelis intervient : aider les équipes techniques à intégrer l’IA dans leurs pratiques de développement sans perdre la maîtrise de ce qu’elles livrent.