Le développement logiciel assisté par IA entre dans une nouvelle phase. Après l’enthousiasme autour du « vibe coding », cette pratique qui consiste à décrire en langage naturel ce que l’on veut construire et à laisser l’IA produire une grande partie du code, les éditeurs cherchent désormais à répondre à une question plus difficile : comment éviter que cette accélération ne crée du chaos, de la dette technique ou des logiciels impossibles à maintenir ?
C’est précisément le terrain sur lequel se positionne Port, spécialiste des plateformes SDLC agentiques. L’entreprise a présenté Port AI Builder, un service destiné aux équipes de platform engineering et de développement, avec une promesse claire : permettre aux organisations d’utiliser des agents IA pour construire des workflows et du logiciel, sans perdre la maîtrise de la gouvernance, de la traçabilité et de la qualité.
Dans un entretien accordé à The New Stack, Zohar Einy, cofondateur et CEO de Port, résume l’enjeu en opposition au « vibe coding slop », autrement dit une forme de production logicielle générée par IA sans discipline, sans contexte métier et sans validation sérieuse. Pour lui, le risque n’est plus seulement d’utiliser l’IA pour développer. Le vrai danger serait plutôt de laisser les concurrents l’adopter plus vite, tout en restant bloqué dans des processus trop lents.
Pourquoi le « vibe coding » seul ne suffit pas en entreprise
Le « vibe coding » a rendu visible une évolution majeure : il n’est plus nécessaire de tout écrire à la main pour produire une application, un script, une intégration ou un outil interne. Les développeurs peuvent formuler une intention, décrire un besoin métier, demander une architecture ou générer des tests. Des outils comme Claude, Cursor ou Lovable ont popularisé cette approche, en particulier auprès des développeurs qui veulent itérer rapidement.
Mais ce modèle montre vite ses limites lorsqu’il entre dans un contexte d’entreprise. Un agent IA qui génère du code sans connaître l’architecture réelle, les dépendances existantes, les règles de sécurité, les responsabilités des équipes ou les objectifs de niveau de service peut produire une solution séduisante en apparence, mais fragile en production.
Les principaux risques sont connus :
- du code difficile à maintenir, car généré sans tenir compte des conventions internes ;
- des décisions d’architecture incohérentes avec les choix déjà validés par l’entreprise ;
- une dette technique accélérée si les validations humaines disparaissent ;
- une perte de traçabilité sur l’origine des changements et les décisions prises ;
- des problèmes de conformité lorsque les workflows IA ne sont pas audités.
Le message de Port est donc moins anti-IA qu’anti-improvisation. L’entreprise défend une IA de développement capable de travailler avec le contexte réel de l’organisation, et non à partir de modèles génériques.
Port AI Builder : un outil pour encadrer les workflows agentiques
Port AI Builder s’inscrit dans la plateforme SDLC agentique de Port. L’idée est de permettre aux équipes de créer et d’exécuter des workflows pilotés par des agents IA, tout en conservant des mécanismes de contrôle adaptés aux environnements de production.
Le service combine plusieurs briques :
- le langage naturel, pour décrire ce que l’on veut construire ou automatiser ;
- l’expertise de domaine, afin que l’IA comprenne les contraintes de l’organisation ;
- des contrôles contextuels, reliés à la stack réelle et aux règles internes ;
- une revue humaine intégrée, avec validation avant exécution ;
- une traçabilité des plans et décisions, utile pour l’audit et la gouvernance.
Selon Zohar Einy, l’objectif n’est pas de « promouvoir le chaos agentique », mais de rendre le développement assisté par IA exploitable dans des environnements sérieux. En clair : l’IA peut accélérer, mais elle ne doit pas court-circuiter les responsabilités humaines, les politiques internes ni les exigences opérationnelles.
Le « Plan Mode », ou comment forcer la clarté avant de générer
L’un des mécanismes clés mis en avant par Port est le Plan Mode. Avant de construire, l’agent rédige un plan, pose des questions de clarification et attend une approbation. Les plans sont ensuite versionnés et conservés, ce qui permet de comprendre ce qui a été demandé, validé et exécuté.
Cette logique répond à un problème fréquent avec les assistants IA de développement : ils produisent vite, mais n’explicitent pas toujours suffisamment leurs hypothèses. Or, dans un système logiciel complexe, une hypothèse implicite peut coûter cher. Par exemple, un agent peut supposer qu’un service accepte une certaine charge, qu’une API interne est stable ou qu’un changement de schéma de base de données n’aura pas d’impact. Sans étape de planification validée, ces suppositions peuvent passer inaperçues.
Avec un mode de planification, l’équipe peut reprendre la main sur les points critiques :
- le besoin métier est-il bien compris ?
- les dépendances techniques sont-elles identifiées ?
- les risques de sécurité et de conformité sont-ils couverts ?
- les tests nécessaires sont-ils prévus ?
- la mise en production respecte-t-elle les règles internes ?
Pour Port, cette approche rend les développeurs plus responsables, y compris les profils juniors. Zohar Einy estime même qu’avec ce type d’encadrement, un ingénieur junior peut bénéficier aujourd’hui de plus de supervision qu’un ingénieur senior n’en avait auparavant.
Le développement ne se résume plus à mémoriser la syntaxe
L’un des points les plus intéressants du discours de Port concerne l’évolution du métier de développeur. Dans l’ère agentique, la compétence centrale n’est plus seulement la capacité à mémoriser une syntaxe ou à écrire rapidement du code ligne par ligne. Elle se déplace vers la capacité à lire, comprendre, évaluer et orienter ce que l’IA produit.
Cette évolution ne signifie pas que les fondamentaux techniques deviennent inutiles. Au contraire, ils deviennent plus importants pour valider les choix proposés par les agents. Un développeur doit être capable de repérer une abstraction inutile, une faille potentielle, une dépendance mal choisie ou une architecture qui ne passera pas l’épreuve de la production.
Dans ce contexte, l’IA devient un accélérateur, mais pas un substitut complet au jugement technique. Les équipes les plus efficaces seront probablement celles qui sauront combiner :
- des prompts précis et contextualisés ;
- une bonne compréhension de l’architecture existante ;
- des standards de code explicites ;
- des revues humaines ciblées sur les zones à risque ;
- des tests automatisés et des validations d’architecture.
Le rôle du Context Lake : donner à l’IA la réalité de l’entreprise
Port insiste sur une notion centrale : le contexte. Un agent IA générique peut connaître des frameworks, des patterns logiciels ou des bonnes pratiques globales. Mais il ne connaît pas spontanément les décisions passées d’une organisation, ses équipes, ses pipelines CI/CD, ses conventions de nommage, ses contraintes SLA, ses outils de ticketing ou ses règles de gouvernance.
C’est là qu’intervient le Context Lake de Port. Cette couche vise à fournir aux agents une vue structurée de l’environnement réel de l’entreprise : stack technique, données opérationnelles, responsabilités d’équipes, règles de conformité, workflows existants et décisions d’architecture.
Cette approche permet aux agents de générer des workflows adaptés à l’organisation plutôt que des solutions théoriques. Par exemple, un agent chargé de résoudre automatiquement un ticket Jira ne devrait pas seulement corriger un bug. Il devrait aussi comprendre quel service est concerné, quels tests de régression lancer, quelles dépendances transverses vérifier et quel processus d’approbation respecter.
Port présente ainsi son AI Builder comme une couche construite au-dessus de sa plateforme SDLC agentique existante, qui couvre déjà l’orchestration de workflows, la gestion d’agents, le contexte et la gouvernance nécessaires pour industrialiser l’IA dans le cycle de développement logiciel.
Des cas d’usage concrets : tickets, tests, coûts IA et performance engineering
La promesse de Port AI Builder ne se limite pas à générer du code applicatif. L’entreprise vise aussi le platform engineering, où les équipes cherchent à automatiser les processus internes sans multiplier les scripts isolés et les outils non contrôlés.
Parmi les cas d’usage évoqués, on retrouve :
- la résolution autonome de tickets, par exemple lorsqu’un développeur ouvre un ticket Jira pour un bug ou une régression ;
- les tests de régression, avec vérification des impacts sur plusieurs services ;
- l’analyse des dépendances de code entre équipes ou domaines fonctionnels ;
- la gestion des coûts IA, un sujet de plus en plus important à mesure que les agents se multiplient ;
- le suivi de la performance engineering, pour mesurer l’efficacité des équipes et des workflows.
Ce positionnement est important : l’IA ne sert pas uniquement à écrire de nouvelles fonctionnalités. Elle peut aussi aider à fluidifier les opérations, réduire les temps d’attente, accélérer les validations et rendre les chaînes de développement plus observables.
Claude, Cursor, Lovable : une inspiration, mais pas le même terrain
Port cite des outils comme Claude, Cursor et Lovable parmi les inspirations de son approche. Ces solutions ont contribué à populariser le développement piloté par prompts, chacune à sa manière : assistance conversationnelle, édition de code augmentée ou création d’applications à partir d’instructions en langage naturel.
La différence tient au périmètre. Là où de nombreux outils de génération s’adressent d’abord à l’individu ou à l’équipe projet, Port veut intégrer cette logique à l’échelle du cycle de vie logiciel complet. Le défi n’est donc pas seulement de produire du code plus vite, mais de faire fonctionner des agents dans des processus d’entreprise, avec des règles, des validations et une visibilité centralisée.
Jim Mercer, vice-président programme pour le développement logiciel et le DevOps chez IDC, cité par la source, résume cette bascule : lorsque les ingénieurs peuvent définir des workflows agentiques en langage naturel et les exécuter sur l’ensemble du cycle de vie, la différence se joue sur le contexte et la gouvernance à grande échelle.
L’onboarding assisté par IA et l’approche agnostique de Port
Port met également en avant un onboarding assisté par IA. L’objectif est de simplifier la configuration initiale et la gestion continue de la plateforme, tout en conservant la cohérence opérationnelle. Dans les grandes organisations, l’adoption d’un outil de gouvernance peut être freinée par la complexité du paramétrage. L’automatisation de cette étape devient donc un argument important.
L’entreprise revendique aussi une approche ouverte et agnostique. Les développeurs peuvent créer des workflows directement dans Port ou connecter des agents existants. L’enjeu est que ces agents restent visibles, contrôlés et gouvernés au même endroit.
Cette approche répond à une réalité du marché : les entreprises n’utiliseront pas un seul assistant IA. Elles auront souvent plusieurs modèles, plusieurs agents spécialisés et plusieurs outils de développement augmentés. Sans couche de gouvernance commune, cette diversité peut vite devenir difficile à piloter.
La dette technique vient-elle de la vitesse ou du manque de gouvernance ?
Une inquiétude revient régulièrement autour du développement assisté par IA : si les équipes vont plus vite, ne risquent-elles pas de produire davantage de dette technique ? Pour Zohar Einy, le problème ne vient pas de la vitesse en elle-même, mais des goulots d’étranglement et des décisions trop lentes. Selon lui, les humains créent aussi de la dette technique lorsqu’ils sont débordés, pressés ou contraints de contourner des processus trop lourds.
Son argument est simple : une IA supervisée peut retirer certains blocages tout en conservant le jugement humain aux bons endroits. Autrement dit, la gouvernance ne devrait pas être un frein opposé à la rapidité, mais un cadre qui permet d’aller vite sans perdre le contrôle.
Cette idée mérite toutefois d’être nuancée. L’IA avec supervision peut réduire certains risques, mais elle ne les supprime pas automatiquement. Pour fonctionner, une telle approche suppose que les organisations définissent clairement :
- les zones où les agents peuvent agir seuls ;
- les changements qui exigent une validation humaine ;
- les critères de qualité et de sécurité non négociables ;
- les mécanismes d’audit et de rollback ;
- les responsabilités en cas d’erreur ou d’incident.
Sans ces règles, le « vibe coding » peut effectivement devenir une machine à produire du logiciel approximatif. Avec elles, il peut devenir une nouvelle interface pour orchestrer le développement.
Ce que les équipes tech doivent retenir
L’annonce de Port AI Builder illustre une tendance plus large du marché : l’IA de développement quitte progressivement le simple assistant de code pour entrer dans l’orchestration du SDLC. Les agents ne se contentent plus de compléter des fonctions ; ils peuvent planifier, analyser, tester, documenter et déclencher des workflows.
Pour les DSI, les responsables platform engineering et les équipes DevOps, le sujet prioritaire devient donc moins « faut-il utiliser l’IA ? » que « comment l’utiliser sans perdre la gouvernance ? ». Les organisations qui veulent avancer devraient commencer par quelques principes pratiques :
- cartographier les processus existants avant d’y injecter des agents IA ;
- documenter les décisions d’architecture pour les rendre exploitables par les outils ;
- standardiser les validations selon le niveau de risque des changements ;
- mesurer les gains réels, pas seulement le volume de code généré ;
- former les développeurs à relire et orienter l’IA, plutôt qu’à lui déléguer aveuglément.
Le développement logiciel assisté par IA ne sera durable que s’il s’appuie sur du contexte, de la visibilité et une responsabilité claire. C’est le message que Port veut faire passer avec AI Builder : le futur du code ne sera pas seulement plus rapide, il devra aussi être versionné, auditable et approuvé.
Le « vibe coding » a ouvert une porte. La prochaine étape consiste à construire les garde-fous qui permettront aux entreprises de l’emprunter sans transformer leur système d’information en terrain d’expérimentation incontrôlé.