Partie 1 — Vibe coding vs ingénierie agentique

Atecna — On entend beaucoup parler d’IA dans le développement. Concrètement, qu’est-ce qui est en train de changer ?

Lamine Camara — On vit un vrai basculement : on ne code plus seulement plus vite, on pense le développement différemment. Et il faut distinguer deux choses qu’on confond souvent.

Le « vibe coding« , c’est une posture : on génère du code à partir d’intuitions ou de prompts, sans trop réfléchir à la structure. C’est rapide, mais ça peut vite tourner au chaos. L’IA amplifie ce qu’on lui donne — une mauvaise base, elle construit dessus très vite et très loin. Et le piège, c’est qu’on ne s’en rend compte que tard : la dette technique s’accumule en silence, à une vitesse qu’on n’aurait jamais atteinte sans IA.

C’est pour ça qu’un accompagnement est indispensable — pas pour ralentir, mais pour éviter que la vitesse devienne incontrôlable. Un référent technique qui pose une architecture minimale, des conventions, quelques garde-fous. Sans ça, on va vite dans le mur, et on ne le voit pas venir.

L’ingénierie agentique, c’est autre chose : une architecture où des programmes autonomes — les agents — prennent en charge des tâches. Ce sont deux dimensions distinctes. On peut faire du vibe coding avec des agents, ou de l’ingénierie agentique de façon très rigoureuse. L’un ne remplace pas l’autre.

Atecna — Le « vibe coding », c’est déjà une révolution pourtant, non ?

Lamine Camara — Oui, mais c’est une première étape, et elle a ses limites. C’est très puissant pour prototyper rapidement, tester une idée ou produire une démo. Le problème, c’est que ça donne parfois une illusion de produit fini. En réalité, le code généré « à l’intuition » est souvent difficile à maintenir, à sécuriser ou à faire évoluer. Ce n’est pas un jugement moral — c’est juste qu’un bon produit nécessite de la rigueur que le vibe coding seul ne garantit pas.


Partie 2 — Ce que font vraiment les agents aujourd’hui

Atecna — Et l’ingénierie agentique change la donne ?

Lamine Camara — Oui, mais il faut être précis sur ce qu’on peut faire aujourd’hui versus ce qu’on espère faire demain. Aujourd’hui, un agent peut prendre en charge une tâche bien délimitée : corriger un bug, générer des tests unitaires, mettre à jour une documentation. Là, ça marche plutôt bien avec une supervision humaine. Mais si on lui demande de gérer une base de code de plusieurs dizaines de milliers de lignes, de A à Z, en production, avec des contraintes de sécurité — on n’y est pas encore. Les agents actuels hallucinent encore, se trompent, créent des régressions.
L’idée d’agents qui « codent, testent et déploient » en parallèle existe — il y a des frameworks comme LangGraph, CrewAI ou AutoGen qui permettent d’orchestrer ça — mais en pratique, ça reste très supervisé et expérimental en dehors de contextes très contrôlés.

Atecna — Justement, on parle de gains importants…

Lamine Camara — Les gains existent, et ils peuvent être significatifs — les études de GitHub montrent des accélérations de 30 à 55 % sur certaines tâches bien définies. Mais le « multiplié par 3 » qu’on entend parfois, c’est une extrapolation optimiste. Tout dépend du type de tâche : rédiger des tests unitaires répétitifs, l’IA excelle. Concevoir une architecture ou déboguer un problème complexe — les gains sont bien moindres, voire nuls.
Et surtout : ces gains ne se matérialisent pas tout seuls. Un débutant sans encadrement va produire vite, mais mal. Un senior sans recul va accepter des suggestions incorrectes parce qu’elles semblent convaincantes. Une équipe aguerrie sans processus de validation va accumuler des erreurs silencieuses difficiles à tracer. À chaque niveau, il faut un humain qui comprend, qui valide, qui corrige. L’IA accélère — elle ne se supervise pas elle-même.


Partie 3 — Où en est-on vraiment ?

Atecna — Comment une organisation peut-elle se situer aujourd’hui ?

Lamine Camara — Voici comment je découpe les niveaux de maturité, avec leurs réalités concrètes :

NiveauCe que ça veut direLimites réelles
1 — AutocomplétionCopilot, suggestions de code en temps réelRéduit la fatigue mais ne change pas l’architecture du projet
2 — AssistantOn lui pose des questions, il génère des blocs de codeLe développeur reste le pilote à 100 %
3 — Agent superviséL’IA exécute des tâches définies avec supervision humaineSupervision dense encore nécessaire, erreurs fréquentes sur bases de code larges
4 — Multi-agents (émergent)Plusieurs agents collaborent en parallèleGestion des conflits, coûts élevés, débogage très complexe — encore expérimental

Atecna — Et l’objectif final ?

Lamine Camara — On parle souvent de « software factory » — partir d’un besoin métier et générer automatiquement un système complet. C’est une vision séduisante, mais on en est encore loin. Les besoins métier sont rarement clairs et sans ambiguïté, la sécurité ne se génère pas automatiquement, et savoir si un système fait vraiment ce qu’on lui demande reste un problème ouvert. C’est une direction de recherche, pas un horizon proche.


Partie 4 — Ce que ça change pour les équipes

Atecna — Qu’est-ce que ça change pour les développeurs back-end ?

Lamine Camara — Le rôle évolue, et le nouveau cœur de métier est désormais clair : savoir découper les problèmes pour décider ce qu’on confie aux agents, ce qu’on supervise, et ce qu’on refuse d’automatiser. Qu’est-ce qui est traitable par un agent seul ? Qu’est-ce qui nécessite une supervision humaine ? Qu’est-ce qui est trop risqué ? Ce sont ces questions-là qui structurent désormais le travail.
Pour y répondre, ça exige des compétences très techniques : savoir écrire de bons prompts pour des agents, comprendre les limites de contexte des modèles, gérer les coûts d’inférence, et mettre en place de l’observabilité — c’est-à-dire être capable de savoir si un agent a bien fait son travail ou pas.
Donc oui, on définit davantage les objectifs et on supervise. Mais réduire ça à « on devient des architectes » serait trop simple. C’est bien plus concret, et bien plus technique, que ça.

Atecna — Et pour les managers ou les entreprises ?

Lamine Camara — Il y a trois décisions clés à prendre sérieusement : comprendre son niveau de maturité réel (pas celui qu’on imagine), investir au bon endroit — pas forcément dans les outils les plus chers, souvent dans la formation et les processus — et repenser l’organisation du travail. Les équipes doivent apprendre à travailler avec l’IA : comment définir une tâche pour qu’un agent la réussisse, comment vérifier son output, comment gérer les erreurs.


Partie 5 — Conseils pour démarrer

Atecna — Un conseil pour démarrer ?

Lamine Camara — Ne pas se focaliser uniquement sur les outils. Ce n’est pas en installant le dernier framework agentique qu’on va transformer son équipe. La vraie question, c’est : est-ce que vous êtes capables d’évaluer ce que produit l’IA ? Si vous n’avez pas de critères clairs pour juger si un agent a bien fait son travail, vous ne pouvez pas l’intégrer sérieusement dans votre workflow. C’est ça, le vrai point de départ : construire des « evals », des critères d’évaluation, avant même de choisir un outil.
Ensuite, commencez petit. Identifiez une tâche répétitive, bien définie, à faible risque. Automatisez-la avec un agent. Mesurez. Apprenez. Puis montez en puissance progressivement.

Atecna — Un mot de conclusion ?

Lamine Camara — On est au début d’un changement profond, c’est vrai. Mais ce changement n’est pas magique — il demande autant de rigueur que ce qu’on a toujours fait en ingénierie logicielle, peut-être même plus. Ceux qui verront l’IA comme un simple générateur de code passeront à côté. Ceux qui la traitent comme un système à part entière — avec ses forces, ses limites, ses risques — et qui construisent des processus autour, ceux-là vont créer un vrai avantage. Pas en quelques semaines, mais en quelques trimestres d’apprentissage sérieux.

Vous avez des questions ou souhaitez discuter de projets IA ?

N’hésitez pas à contacter les experts d’Atecna.