Il y a deux ans, je vous montrais comment développer avec l’IA grâce à Ollama et Continue. À l’époque, l’assistant commentait mon code et corrigeait quelques erreurs de syntaxe. Aujourd’hui, il écrit des fonctionnalités entières, des tests et même des scripts de déploiement.
Alors forcément, la question revient souvent : a-t-on encore besoin d’un architecte logiciel ?
Spoiler : oui. Et même plus qu’avant. On fait le point ensemble.
Écrire du code n’a jamais été le plus difficile
Qu’on se le dise, taper des lignes de code n’a jamais été la partie la plus délicate de notre métier. Le vrai défi, c’est de savoir quoi construire, comment le découper et pourquoi faire tel choix plutôt qu’un autre.
L’IA a considérablement accéléré l’écriture. Elle n’a pas fait disparaître ces questions. Au contraire : plus le code s’écrit vite, plus les mauvaises décisions se propagent vite, elles aussi.
Ce que l’IA fait très bien
Soyons honnêtes, je l’utilise tous les jours, et elle me fait gagner un temps précieux sur :
- le code répétitif et les tâches sans surprise ;
- la génération de tests et de jeux de données ;
- l’explication d’un code existant que l’on découvre ;
- la documentation, les messages de commit, les scripts du quotidien ;
- les premiers jets d’un prototype.
Bref, tout ce qui relève de l’exécution. Et c’est déjà énorme !
Ce qui ne se délègue pas
Le découpage du système
Un assistant répond à la question que vous lui posez. Il ne voit pas l’ensemble : les modules qui vont grossir, les services qui devront passer à l’échelle, les frontières qu’il ne faudra jamais franchir. Découper un logiciel, c’est décider de ce qui doit rester simple, et de ce qui a le droit d’être compliqué.
Les choix techniques, et surtout leurs raisons
Demandez à une IA de choisir entre deux frameworks : elle vous donnera une réponse plausible. Mais elle ne connaît ni votre équipe, ni votre existant, ni la personne qui maintiendra le logiciel dans cinq ans. Un choix d’architecture se justifie, se documente et s’assume.
La sécurité et les données
Gestion des secrets, droits d’accès, données personnelles, dépendances vulnérables… Le code généré fonctionne souvent du premier coup, ce qui ne veut pas dire qu’il est sûr. C’est justement là que la relecture d’un œil expérimenté fait toute la différence.
Les contraintes du métier
Chez Keranova, j’ai travaillé sur le logiciel d’un robot de chirurgie laser de la cataracte, soumis à la norme IEC 62304 des dispositifs médicaux. Traçabilité, revues de code, règles MISRA : aucune de ces exigences ne se négocie avec un assistant, aussi doué soit-il.
La responsabilité
Quand un logiciel tombe en production, on ne se retourne pas vers le modèle de langage. Quelqu’un doit comprendre ce qui a été livré, pourquoi, et comment le corriger. Ce quelqu’un, c’est l’équipe, et c’est souvent l’architecte.
Un exemple concret : prototyper avant de construire
Sur la refonte de SOGo 6, le groupware open source d’Alinto, le travail n’a pas commencé par du code de production. Il a commencé par des propositions d’architecture, des études techniques et des prototypes, comme un serveur MAPI, pour lever les points à risque avant de s’engager.
Ce n’est qu’ensuite que le développement a démarré : services Python, déploiement sur Kubernetes, traitements asynchrones confiés à Celery. L’IA peut accélérer chacune de ces étapes. Elle ne remplace pas la décision de les faire dans cet ordre.
Mes règles pour travailler avec un assistant d’IA
- Le cadre d’abord : architecture, conventions et interfaces sont définies avant de générer quoi que ce soit.
- Des petites tâches : l’assistant avance par étapes courtes, faciles à relire.
- Des tests : tout code généré est couvert, ou il ne part pas.
- Une vraie relecture : un code que personne n’a compris n’est pas un code terminé.
- Aucun secret dans les requêtes : mots de passe, clés et données clients restent chez vous (un modèle local, comme Ollama, aide beaucoup).
- Des décisions écrites : chaque choix structurant est documenté, pour l’équipe comme pour le prochain qui passera par là.
En résumé
L’IA est une formidable accélératrice. Elle écrit plus vite que nous, et c’est tant mieux ! Mais un logiciel qui tient dans la durée reste le fruit de décisions humaines : un découpage réfléchi, des choix argumentés, une sécurité maîtrisée et une responsabilité assumée.
Vous lancez un projet, ou vous reprenez une application écrite (en partie) par une IA ? Découvrez comment je travaille comme architecte logiciel Python à Lyon, ou faites le point avec un audit de code. Et si vous voulez en discuter, entrons en communication !
