Le codage manuel est l’exception et non la règle au sein de Visma. Le rôle des développeurs évolue, mais en fin de compte, ils demeurent responsables du code.
Le développement logiciel se trouve à un tournant crucial en 2026. Il existe autant d’opinions sur le codage automatisé qu’il y a d’outils pour le réaliser. Le groupe de logiciels norvégien Visma a fait un choix clair : « L’ère du codage manuel est révolue », déclare Diana Viorica Bara, directrice du développement produit chez Visma.
Mme Bara travaille dans le développement logiciel depuis vingt-cinq ans et a rejoint Visma il y a dix-huit ans. Depuis février 2025, elle occupe un rôle de direction au sein du développement produit. À ce titre, elle accompagne les entreprises dans leur transformation vers l’IA.
Plus qu’une simple assistance
Visma n’a pas changé de cap par hasard. « Le déploiement a commencé par des applications pratiques où la valeur et l’impact étaient évidents, comme l’assistance au code, la documentation, le prototypage et les tests. À partir de là, cela s’étend à d’autres couches », explique Mme Bara.
La première phase de l’IA dans le développement logiciel était principalement axée sur l’assistance. Mme Bara : « Les développeurs appuient sur un bouton et le code apparaît. S’en est suivie une phase de supervision, où l’humain et l’IA collaborent plus étroitement sur une même tâche. »
Pour Mme Bara, la valeur ajoutée réside dans les phases suivantes : la délégation et l’orchestration. « Les agents d’IA peuvent traiter plus d’une tâche définie, ils peuvent gérer un flux de travail complet. De nombreuses étapes du cycle peuvent déjà être prises en charge par l’IA. Le développeur humain reste toutefois responsable du contexte et du résultat. »
Stratégie partagée et autonomie locale
Visma a donc opéré ce changement en interne : le codage manuel doit être l’exception et non plus la règle. Mme Bara voit les bénéfices les plus nets en termes de rapidité et de productivité. « Les développeurs n’ont plus à effectuer de tâches lentes, répétitives et coûteuses. L’impact de l’IA est significatif lorsqu’elle est appliquée au bon travail. »
Mme Bara cite un exemple interne. « Grâce à l’IA, nous avons réussi à moderniser un système de paie complexe en 6 semaines avec une équipe de 3 personnes, alors que nous estimions que cela aurait pris cinq ans autrement. Dans certains cas, nous pouvons déjà réduire le travail humain de 90 %. Cela nous permet également de déployer plus rapidement des améliorations et des fonctionnalités d’IA pour nos clients. Les systems of record évoluent vers des systems of action : le logiciel n’a plus besoin d’attendre que vous cliquiez. »
Le groupe Visma compte plus de 180 entreprises possédant leurs propres logiciels, clients et environnements informatiques. L’objectif n’est pas de changer l’identité de ces entreprises Visma, mais de les aider à exploiter tout leur potentiel. « Il existe une stratégie commune, mais avec une autonomie locale pour nos entreprises. Elles peuvent tester elles-mêmes ce qui fonctionne le mieux pour elles. Tous les produits ne contiendront pas le même degré d’IA agentique. L’objectif n’est pas simplement d’ajouter un peu d’IA aux logiciels, mais de transformer l’ensemble du processus. »
Le logiciel n’a plus besoin d’attendre que vous cliquiez.
Diana Viorica Bara, directrice du développement produit chez Visma
L’ouvrier devient architecte
Le degré d’automatisation plus élevé ne signifie pas que Visma met ses développeurs de logiciels à la retraite anticipée. Cependant, leur rôle évolue : d’ouvrier effectuant le gros œuvre, ils deviennent architectes concevant et supervisant les plans. « L’humain reste nécessaire pour orchestrer le travail, valider le code et mettre en place des garde-fous. Il ne s’agit pas seulement de générer du code, mais aussi de comprendre le contexte. Le développeur devient un architecte de résultats », explique Mme Bara.
En fin de compte, la responsabilité incombe toujours aux humains. Selon Mme Bara, c’est crucial pour garantir la sécurité du code. « L’IA offre des opportunités tant que les garde-fous appropriés sont en place. On ne peut pas faire aveuglément confiance au code généré par l’IA. Sans garde-fous, elle ne fait qu’accélérer les erreurs. L’adoption n’est pas seulement une question de rapidité, mais aussi de compréhension de la valeur ajoutée et des risques. »
« Chez Visma, nous prenons cela très au sérieux car nous développons des logiciels critiques pour les entreprises. La validation n’est pas dissociée du processus de développement. La responsabilité des logiciels incombe aux équipes. Si le rôle des développeurs évolue vers l’architecture, ils doivent néanmoins rester proches du code », précise Mme Bara.
Les jeunes développeurs devront apprendre à s’adapter à ces modèles changeants. Auparavant, les profils juniors acquéraient de l’expérience principalement par le codage manuel, mais ils devront désormais s’approprier le codage automatisé. « Le rôle de programmeur devient plus large et plus stratégique. La réflexion orientée produit et la compréhension des besoins des clients deviennent la nouvelle norme. La question n’est pas de savoir si vous utilisez l’IA, mais comment vous l’intégrez dans des flux de travail natifs de l’IA. C’est ce que les développeurs juniors devront apprendre dès le début. Les bases restent importantes, mais l’orchestration devient de plus en plus une compétence clé. »
Le codage manuel appartient au passé
Visma fait progressivement de la programmation manuelle l’exception. Cette évolution ne signifie pas que le développement logiciel devient totalement autonome. Les agents d’IA peuvent exécuter de plus en plus de tâches et de flux de travail, mais les humains doivent fournir le contexte, définir les limites et assumer la responsabilité finale. Ce contrôle reste indispensable, en particulier pour les logiciels d’entreprise gérant des processus critiques.
Mme Bara résume clairement ce changement : « L’ère du code manuel touche à sa fin et une nouvelle phase d’orchestration commence. » Pour Visma, il ne s’agit pas d’un seul outil ou d’une vague éphémère. Il s’agit de faire travailler les équipes de développement différemment, de permettre aux produits d’orchestrer davantage de flux de travail, d’exécuter des actions et de partager les connaissances plus rapidement.