Dans un contexte où l’IA s’invite dans chaque étape du cycle de développement, le rôle du développeur évolue à grande vitesse. Automatisation, nouveaux arbitrages, montée en compétences sur la conception plutôt que sur l’exécution… les repères bougent. Pour comprendre ce qui change réellement dans le quotidien des équipes tech, nous avons interrogé Karim Bourass, Lead Software Engineer à Berexia, qui observe cette transformation de l’intérieur et en mesure déjà les impacts opérationnels.
Selon toi, quel est l’impact réel de l’IA sur le métier de développeur aujourd’hui?
« L’IA n’a pas remplacé le développeur. Elle a déplacé la valeur.
Tout ce qui est boilerplate, scaffolding, conversion de format, tests répétitifs.., oui, c’est largement accéléré. Mais comprendre un besoin métier flou, arbitrer entre des contraintes contradictoires, concevoir une archi qui tient dans le temps ? Ça reste 100% humain.
Le vrai impact c’est ça : celui qui refuse l’IA perd un avantage compétitif réel. Mais celui qui délègue tout sans esprit critique produit de la dette technique à une vitesse jamais vue. »
Quelles tâches l’IA t’aide réellement à accélérer dans ton quotidien de Tech Lead, et lesquelles tu refuses de déléguer ?
« Concrètement, l’IA m’aide énormément sur :
- Le scaffolding de modules backend/frontend (guards, interceptors, DTOs, structure de base, test).
- Les requêtes SQL complexes, surtout quand tu bosses sur plusieurs schémas avec des agrégations lourdes.
- La rédaction de documentation technique.
- Le debugging exploratoire quand tu tombes sur un système legacy que tu connais pas
Ce que je refuse de déléguer ? Les décisions d’architecture. Le design d’API entre services. Et le code review final (PR). L’IA ne comprend pas ton contexte orga, les contraintes du client, ni les compromis que tu acceptes sciemment. »
Peux‑tu partager un exemple concret où l’IA a amélioré un delivery ou débloqué une situation technique ?
- « Sur un projet de scoring ML, il fallait extraire des features depuis cinq schémas différents en base. Des jointures complexes, des agrégations temporelles, beaucoup de va-et-vient. D’habitude c’est deux à trois jours de SQL pur. Là, je décrivais la logique métier, l’IA générait le SQL, je validais et ajustais. Bouclé en une demi-journée.
- Autre cas : intégrer un connecteur vers une API CRM que je ne connaissais pas en détail. L’IA a accéléré toute la phase d’exploration, ce qui m’a permis de me concentrer sur la robustesse et la gestion d’erreurs plutôt que de lire de la doc pendant des heures. »
Comment tu accompagnes les développeurs (seniors et juniors) pour qu’ils utilisent l’IA sans devenir dépendants ?
« Un junior qui copie-colle du code généré par l’IA sans chercher à comprendre ce qu’il fait, il progresse pas, il accumule de l’ignorance technique sans s’en rendre compte. L’IA c’est un accélérateur, pas un prof. Moi en PR review, je pose toujours la même question : explique-moi ce que fait ton code. Si t’es pas capable de le défendre, il a rien à faire dans le codebase. Peu importe qui l’a écrit.
Côté seniors, le piège est différent mais tout aussi dangereux : c’est la paresse intellectuelle. Quand tu commences à laisser l’IA réfléchir à ta place sur l’archi ou les edge cases, t’es en train de régresser. Et c’est sournois parce que le résultat a l’air propre.
Au final, le principe est le même pour tout le monde : l’IA génère, toi tu valides et tu assumes. »
Est‑ce que l’IA change ta manière de faire du code review ou de transmettre les bonnes pratiques ?
« Clairement oui. Avant, une bonne partie du review portait sur des erreurs de nommage, structure, patterns manquants. L’IA a réduit ce bruit. Aujourd’hui le review se concentre sur les vrais sujets : cohérence avec le codebase, implications sécu, maintenabilité long terme.Mais il y a un piège. Le code généré par l’IA est souvent « correct mais générique ». Ça compile, ça passe les tests basiques, mais ça ne respecte pas forcément tes conventions internes ou tes contraintes de perf. Faut être encore plus vigilant. »
Quels risques tu observes quand une équipe utilise l’IA sans cadre clair (qualité, sécurité, dette technique) ?
« La première chose à éviter, c’est le vibe coding pur, balancer un prompt, récupérer une feature en one shot et push sans réfléchir. Ça marche une fois, mais à l’échelle d’un projet c’est une bombe à retardement. Sans cadre clair, tu te retrouves avec trois problèmes : de la dette technique invisible parce que le code IA a l’air propre mais il est verbeux, inconsistant avec ton codebase existant. Des fuites de données parce que des devs collent du code métier, des credentials ou des schémas de base dans des prompts sans se poser de questions. Et une érosion des compétences, une équipe qui sait plus écrire du SQL, debugger à la main ou comprendre ce que fait l’ORM sous le capot, c’est une équipe qui tient debout uniquement tant que l’IA couvre son cas. Le jour où c’est pas le cas, y’a personne pour prendre le relais. »
Selon toi, quelles compétences humaines resteront indispensables pour un développeur dans un environnement où l’IA est omniprésente ?
« Pour moi la compétence qui aura le plus de valeur demain, c’est pas d’écrire du code, c’est de comprendre un besoin métier, souvent flou, et de le traduire en une architecture technique clean qu’on peut implémenter en utilisant des outils IA. La partie 100% code pur, on l’a dépassée. Utiliser des outils IA aujourd’hui c’est plus un luxe, c’est une obligation. Celui qui ne les adopte pas se met tout seul en retard. »
