Assistant de code

Comment ça marche

Un assistant de code est un modèle de langage entraîné sur d’immenses quantités de programmes, intégré dans un outil qui lui donne accès au code. Au niveau le plus simple, il complète ce qu’on tape. Au niveau suivant, il discute du code, l’explique, le modifie sur demande, dans un éditeur. Au niveau le plus avancé, il devient un agent : on lui donne une tâche, il lit les fichiers, écrit, exécute, teste, corrige, et rend compte.

Ce qui a changé en deux ans, c’est ce dernier niveau. Un agent de code ne se contente pas d’aider à écrire : il construit. Un script qui n’existait pas, une petite application, une automatisation, une analyse de données. Il travaille dans vos fichiers, depuis le terminal ou l’éditeur, avec des permissions qu’on règle. Pour une entreprise qui n’a pas de développeur, c’est l’accès à des outils sur mesure qui étaient hors de portée.

Un exemple concret

1. Le développeur qui maintient l’outil de gestion utilise un éditeur assisté : complétion, explication du code hérité, modifications guidées. Il écrit toujours le code ; il va deux fois plus vite.
2. La responsable qualité, qui ne code pas, utilise un agent : « Lis les rapports d’incidents du trimestre et produis un tableau par site, par type et par gravité, avec un graphique. » L’agent écrit le script, l’exécute, livre le tableau. Elle relit les chiffres.
3. Le dirigeant a demandé à l’agent un tableau de bord hebdomadaire qui lit les exports de trois logiciels et produit une page. L’agent l’a construit en deux jours avec des tests ; le développeur l’a relu et l’a mis en production.

Le même modèle sous les trois outils. La différence est dans ce qu’on lui délègue, et dans qui relit.

Ce que ça change pour une équipe

• Les outils sur mesure deviennent abordables. Un besoin précis, décrit clairement, devient un outil en jours. Ce qui n’était pas rentable à faire développer le devient.
• Les développeurs changent de rôle. Moins d’écriture, plus de spécification, de revue et d’architecture. Et une production bien supérieure.
• Les non-développeurs accèdent au code. Avec un cadre : organisation des fichiers, Git, permissions, tests, et quelqu’un qui relit.
• La qualité devient une question de méthode. Spécification, tests avant le code, revue : ce qui fait la différence entre un outil qui dure et un prototype qui casse.

Les limites et les erreurs fréquentes

• Accepter sans relire. Le code a l’air bon, les tests passent, on intègre. La revue est ce qui sépare l’assistant de code du vibe coding.
• Des demandes vagues. « Fais un outil pour les devis » donne un outil qui fait ce que l’agent a imaginé. La spécification est le travail principal.
• Pas de filet. Sans Git, une modification malheureuse est irréversible. Sans tests, une régression passe inaperçue. Les deux se mettent en place avant.
• Croire que le prototype est le produit. Un outil qui marche en démo n’a pas été pensé pour les données réelles, la sécurité, la maintenance. Le passage en production est une étape à part.