Qu'on le veuille ou non, l'IA s'invite dans notre activité de freelance à travers les clients et les projets sur lesquels on est amené à travailler et elle est de plus en plus présente. Aussi, aujourd'hui je voulais partager avec l'évolution que j'ai pu observer dans la place qu'à l'IA dans mes projets Freelance.
Depuis 2 ans environ un nouveau type de demande a fait son apparition : la reprise de projet IA. Dans le cadre de ces projet le client a déjà commencer à créer une première version de son application à l'aide d'un LLM ou autre outil pour Vibe coder. Mais au fur et à mesure que la complexité du projet grandit les modèles n'arrivent plus à suivre (introduction de bug, difficulté à obtenir un résultat correspondant à ce qui est imaginé) et c'est la que le client finit par faire appel à un développeur humain.
La particularité de ce type de projet est qu'au moment de la demande, le client présente déjà une application fonctionnelle partiellement. Ce qui s'avère plutôt intéréssant lorsqu'il s'agit de spécifier le travail à accomplir. Le client a pu tester une première version de ce qu'il voulait faire et a maintenant une idée plus clair de ce qu'il cherche à obtenir.
Ce n'est d'ailleurs pas un type de projet si nouveau dans le principe. On rencontrait déjà un problème similaire avec les CMS : les clients utilisaient des outils comme WordPress, Shopify ou autre pour créer une première version de leur site en essayant de s'adapter aux limites de la plateforme. Puis, avec le temps, ils découvraient des limites spécifiques à leur utilisation et ils faisaient alors appel à un développeur. La différence avec les LLM aujourd'hui réside dans le fait qu'ils s'adaptent a des situations plus variées mais la situation est similaire.
Cette utilisation de l'IA se retrouve aussi dans d'autres étapes du projets comme la rédaction des spécifications du projet (ce qui se remarque assez vite car les LLM expriment souvent des choix technologique sans aucune raison).
En revanche, un inconvénient majeur pour ces types de projet, c'est le fait de devoir partir de zéro pour commencer à travailler. Le code généré par une IA manque d'uniformité côté intégration, et le code a tendance à être très verbeux. Les modèles peuvent à tout momen scanner le code pour comprendre les choses avec un contextes assez grand là où un développeur va rappidement se perdre. Une grosse partie du travail de développeur c'est de trouver une bonne méthode d'organisation qui soit à la fois efficace pour travailler mais qui soit aussi pérenne pour l'évolution du projet dans le temps.
De mon côté, je dirais que cette utilisation de l'IA est plutôt positive pour l'activité. Les clients peuvent prototyper et tester plus facilement leur idée avant de faire appel à un développeur pour finaliser / concrétiser le projet. Cela pourrait amener à l'apport de nouveau projet.
En revanche, il est vrai que cela risque de représenter une perte d'activité pour les personnes qui prennaient des missions de petites envergure car cela peut être remplacer par une génération via des LLM. Mais cela implique que le client final soit assez intéréssé par la création pour se lancer dans la création.
L'autre endroit ou j'ai vu l'IA débarquer dans mes missions c'est dans la phase de revue de code. Lorsqu'on travaille en équipe, on soumet nos changements à travers des merge requests (ou pull requests) et d'autres développeurs valident nos changements. Le truc, c'est que dans les équipes que j'ai rejoint récemment, de nouveaux "développeurs" ont fait leur apparition : Claude et Copilot. Dès que je soumet une MR, dans les minutes qui suivent, un petit robot fait des retours.
On avait déjà des processus automatisé de pre-revue avec des linters et des formateurs. Leur rôle : analyser le code et signaler si certains motifs non désirés sont présents (un console.log oublié, une variable inutilisée...). Les LLM poussent cette logique de vérification un plus loin en étant capables de comprendre plusieurs fichiers ensembles mais aussi leur lien avec la fonctionnalité que l'on chercher à développer. Ils peuvent ainsi, avec moins de configuration, couvrir un plus large éventail d'erreurs / problèmes. En dehors, de la consommation astronomique que ce type d'utilisation représente, cela peut sembler être positif comme approche. Vérifier de manière automatique des changements permet de faire gagner du temps aux équipes.
Les problèmes surviennent quand certaines entreprises se disent :
Vu qu'on a un LLM pour faire la review, on va demander aux développeurs d'arrêter de faire la revue manuelle. Ils seront comme ça plus efficaces ! Si le LLM dit que c'est bon, la MR est fusionnée.
Et ça, pour moi, ça représente deux risques majeurs :
Premièrement, les modèles ne sont pas infaillibles et laissent passer beaucoup de choses. Ils ont tendance à se baser sur des remarques généralistes sans forcément faire de comparaison avec le contexte du projet. Ils ne sont pas capable d'évaluer l'impact d'un choix technique sur la suite du projet et peuvent accepter des changements qui peuvent dégardé la maintenabilité du projet sur le long terme.
Deuxièmement, la phase de review est importante parce qu'elle permet de comprendre ce que les autres développeurs font. Si tout le monde fonctionne avec une review automatique, au bout de quelques mois, plus personne n'a de compréhension complète du projet. Quand on arrive sur du code écrit par un collègue, on n'a aucune idée de pourquoi le code existe et ce qu'il est sensé faire car on n'a pas suivi l'origine de sa création.
Si vous êtes manager, même si l'idée de faire gagner du temps est tentante, enlever complètement la phase de revue ne peut avoir qu'un impact négatif sur le long terme.
Par contre, il est vrai que cette usage de revue automatique peut avoir un effet négatif sur certaines missions d'audit avec des clients qui préfèreront utiliser un LLM pour avoir un retour rapide sur ce qui pourrait être amélioré sur le projet. Mais il faut dans ce cas, accepter d'envoyer l'ensemble du code source de l'application à un service tiers (qui a une utilisation des données plutôt opaque). Pas sûr que cela soit accepté par les politiques de beaucoup de société au vu des NDA qu'ils font signer au moment de l'audit de code.
Enfin la dernière situation que j'ai rencontré c'est le suivi de projet fait via un LLM et c'est aussi le cas le plus problématique pour mon activité.
Le scénario est le suivant : on travaille sur un projet, on le livre avec le code source, et on s'attend à être rappelé pour la maintenance et l'évolution du projet. Sauf que le client commence à poster des issues et on remarque qu'elles se ferment toutes seules ! Un autre "développeur" intervient sur le projet : Claude Code. Il répond aux issues, fait les MR correspondantes et le client les accepte en totale autonomie.
Cette utilisation s'avère assez efficace car, contrairement à un projet fait de A à Z par les LLM, le modèle se base sur la structure déjà en place et génère un code plus proche du réel en respectant les standards établis en amont. Tant que la fonctionnalité n'est pas trop complexe (soumise à interprétation) je dois avouer qu'il s'en sort plutôt bien.
Pour l'instant, ça ne concerne pas tous mes clients, mais si cette pratique se développe, ça peut véritablement avoir un impact assez négatif sur l'activité.
Ma dernière réflexion concerne l'utilisation de l'IA par les développeurs eux-même. Un développeur senior qui utilise des outils comme Claude Code ou Codex peut devenir réellement plus rapide sur certaines tâches spécifiques. Ainsi, des projets qui pouvait prendre des semaines peuvent être réduit en quelques jours avec une utilisation intensive des LLM et des agents spécifiquement configuré. Côté client, c'est une bonne nouvelle car cela signifie une baisse des tarifs sur certaines demandes, mais côté freelance ça implique de devoir trouver encore plus de projets pour comencer. Ce qui n'est clairement pas évident car on n'est plus dans l'eldorado qu'on a pu connaître par le passé niveau projet (propulsé par un écosystème de startups très actif). De mon côté je suis dans une période où il est plus difficile de trouver des projets que par le passé et si en plus chaque projet est moins rémunérateurs, cela peut devenir un problème pour l'activité.
Malgré tout ce que je peux lire, je pense que même avec l'avènement des LLM le profil d'un développeur avec de l'expérience est toujours valorisé. Même si les LLM sont de plus en terme de génération de code, le prompt reste le facteur qui a le plus d'influence sur la qualité des résultat et sans connaissance / expérience il est impossible de garantir du code de qualité maintenable dans le temps et sûr.