De nouveaux modèles pour l’ingénierie logicielle à l’ère de l’IA avec les software factories

Il y a quelques mois, Martin Coulombe, notre CEO, a assisté à une conférence de Pragmatic Engineer qui a changé sa façon de réfléchir au rôle de l’IA dans le développement logiciel.

Comme plusieurs organisations d’ingénierie, nous expérimentions déjà beaucoup avec l’IA. Nos développeurs utilisaient de nouveaux outils. Nous construisions des agents. Avec Ambrosia et nos principes d’AI software factory, nous intégrions directement l’IA dans de véritables flux de livraison logicielle.

Dans notre récent article, Comment nous utilisons des agents IA pour aider les équipes logicielles à livrer avec moins de friction, nous avons partagé ce que nous apprenons grâce aux AI software factories que nous avons développées avec Ambrosia, notre approche pour intégrer des agents IA spécialisés directement dans les flux de livraison logicielle.

Ces expérimentations ont renforcé un constat que nous faisons de plus en plus dans notre travail : dès que l’IA peut participer de façon significative à la livraison, améliorer la productivité individuelle n’est plus la question la plus intéressante.

La question devient plutôt : comment l’organisation d’ingénierie elle-même doit-elle évoluer?

‍

Comment l'évolution se passe

Aujourd’hui, la plupart des organisations d’ingénierie deviennent AI-enabled. Les développeurs utilisent des assistants de programmation. Les gestionnaires de projet expérimentent avec l’IA pour structurer des billets. Les équipes génèrent de la documentation ou des cas de test. Chacun trouve des façons d’accélérer certaines parties de son travail.

Les outils changent, mais le modèle opérationnel reste essentiellement le même.

Une organisation d’ingénierie AI-native va plus loin. L’IA participe à l’ensemble du cycle de développement logiciel, de la compréhension des besoins d’affaires et de l’exploration de l’architecture jusqu’à la production de code, aux tests, au déploiement et à la maintenance.

Les personnes et les agents coordonnent le travail ensemble. Le contexte devient une infrastructure partagée. Les mécanismes de contrôle et d’évaluation sont intégrés directement dans les flux de travail. Et le modèle de livraison commence à évoluer autour de ce que cette nouvelle combinaison de capacités humaines et technologiques rend possible.

Cette distinction est importante, parce que simplement ajouter de l’IA à un processus existant peut accélérer certaines activités sans pour autant accélérer l’ensemble du système.

Produire du code plus rapidement déplace le goulot d’étranglement

Lorsque le code devient plus facile à produire, sa production devient moins susceptible d’être la principale contrainte.

D’autres éléments de la livraison prennent alors encore plus d’importance.

Le problème est-il clairement défini? L’équipe dispose-t-elle du bon contexte d’affaires? Les décisions d’architecture sont-elles solides? Les exigences sont-elles suffisamment précises pour que les personnes et les agents puissent agir? Peut-on évaluer le travail généré de manière fiable? Plusieurs flux de travail peuvent-ils avancer en parallèle sans créer de problèmes d’intégration? Construisons-nous la bonne chose dès le départ?

Autrement dit, le goulot d’étranglement se déplace.

C’est pourquoi mesurer la transformation liée à l’IA principalement en fonction du nombre de lignes de code, de la vitesse de programmation ou de la productivité individuelle des développeurs passe à côté d’une grande partie de l’enjeu.

Produire plus de logiciels plus rapidement ne crée de la valeur que si l’organisation est capable de transformer cette capacité supplémentaire en meilleurs résultats.

L’objectif n’est pas de maximiser la génération de code. C’est de réduire la distance entre un besoin d’affaires et un logiciel sécuritaire, maintenable et capable d’y répondre.

Penser en systèmes, pas en prompts

L’un des plus grands changements que nous observons est le passage d’une logique où l’on donne des prompts à l’IA à une logique où l’on conçoit des boucles d’ingénierie dans lesquelles l’IA peut fonctionner.

Un assistant de programmation aide une personne à accomplir une tâche.

Un système de livraison AI-native fournit plutôt aux agents le contexte, les outils, les environnements, les règles et les mécanismes d’évaluation dont ils ont besoin pour collaborer avec les humains à travers un flux de travail complet.

C’est ce que nous appelons une AI software factory : un système de livraison intégré dans lequel les personnes et les agents travaillent ensemble pour transformer des besoins d’affaires en logiciels gouvernés, sécuritaires et maintenables.

Le mot « factory » n’est pas le plus important. C’est tout le système qui l’entoure qui compte.

Un agent a besoin de plus qu’un prompt. Il peut devoir accéder à la documentation du projet, aux décisions d’architecture, aux billets, aux dépôts de code, aux environnements de test, aux logs et aux règles d’affaires.

Il doit comprendre ce qu’il est autorisé à faire. Son travail doit pouvoir être évalué. Certaines actions peuvent nécessiter une approbation humaine. D’autres pourraient éventuellement être réalisées automatiquement.

C’est ici que les connaissances organisationnelles deviennent particulièrement importantes.

Une documentation claire, des connaissances de domaine accessibles, des conventions d’ingénierie bien définies et des décisions bien structurées ne servent plus uniquement à intégrer de nouvelles personnes dans une équipe. Elles deviennent des intrants pour l’ensemble du système composé d’humains et d’agents.

Pour plusieurs organisations, une partie du travail nécessaire pour tirer pleinement profit de l’IA ressemblera donc moins à l’adoption d’un nouvel outil qu’à l’amélioration des fondations mêmes de la livraison logicielle.

L’autonomie doit se mériter

Donner accès à davantage d’outils à un agent ne rend pas automatiquement un flux de travail plus mature.

La meilleure question est plutôt : quel niveau d’autonomie le système a-t-il démontré qu’il pouvait gérer de façon fiable?

Nous voyons l’autonomie comme quelque chose qui devrait augmenter progressivement.

Un agent peut commencer comme assistant et recommander des changements qu’un humain révise systématiquement.

À mesure que sa fiabilité augmente, il peut devenir un contributeur qui produit du travail dans un environnement contrôlé.

Pour des tâches à faible risque et bien comprises, les humains pourraient éventuellement revoir les exceptions plutôt que chaque action individuelle.

Dans des flux de travail plus matures, un agent pourrait compléter des processus clairement définis pendant que les personnes supervisent les résultats.

L’objectif n’est pas d’atteindre l’autonomie complète pour le simple fait d’être autonome. Il s’agit de trouver le bon niveau d’autonomie en fonction de la tâche, du risque et des preuves disponibles.

Cela exige des mécanismes d’évaluation, des critères de succès mesurables, des permissions claires et des points d’approbation humaine.

La gouvernance ne peut pas arriver après l’adoption. Elle doit faire partie de l’architecture.

Ce principe offre aussi aux organisations une façon plus pragmatique d’avancer.

Il n’est pas nécessaire de repenser toute l’organisation d’ingénierie en une seule fois. Commencez avec un flux de travail dont le résultat est clair, où le risque est gérable et où la performance peut être mesurée. Augmentez ensuite le niveau d’autonomie en fonction des résultats démontrés.

Le rôle du développeur se déplace en amont

À mesure que l’IA devient capable de réaliser davantage de tâches d’exécution, la valeur des ingénieurs expérimentés ne disparaît pas. Leur levier change.

La production de code routinière, la recherche d’information, les changements répétitifs et certaines étapes de validation manuelle peuvent de plus en plus être soutenus par des agents.

Cela donne encore plus d’importance au travail qui entoure l’exécution :

Définir le bon problème. Sélectionner le bon contexte. Prendre des décisions d’architecture. Concevoir des systèmes. Superviser l’exécution des agents. Créer des mécanismes d’évaluation efficaces. Reconnaître lorsqu’un résultat est techniquement correct, mais tout de même inadéquat pour l’entreprise.

Ce ne sont pas des compétences secondaires.

Dans un environnement AI-native, elles deviennent des compétences centrales en ingénierie.

Nous l’observons déjà avec Ambrosia.

Lorsqu’un agent peut implémenter un billet ou préparer une pull request, la qualité du billet devient encore plus importante. Lorsqu’un agent peut utiliser la documentation d’un projet, maintenir ces connaissances structurées et à jour devient plus important. Lorsque plusieurs tâches peuvent avancer en parallèle, l’architecture et la coordination prennent davantage de valeur.

L’ingénieur devient progressivement responsable non seulement de produire un résultat, mais aussi de concevoir et de superviser le système qui le produit.

Cela peut créer un levier important. De plus petites équipes pourraient être capables de coordonner davantage de travail en parallèle, pendant que les ingénieurs consacrent plus de temps aux décisions qui nécessitent du jugement, de l’expérience et une compréhension du contexte d’affaires.

Mais ce levier n’existe que si le modèle opérationnel qui l’entoure est adapté.

Construire une organisation AI-native est un défi de modèle opérationnel

C’est pourquoi nous croyons que la prochaine étape de l’adoption de l’IA en ingénierie logicielle portera moins sur le choix d’un assistant de programmation que sur la manière dont les organisations repensent leur modèle de livraison.

Plusieurs questions deviennent importantes :

• Comment le contexte circule-t-il entre les personnes, les agents et les outils?
• Quelles tâches devraient être réalisées de manière autonome, et quelles décisions devraient demeurer fermement humaines?
• Comment évaluer de façon constante le travail généré par l’IA?
• Comment les structures d’équipe évoluent-elles lorsque davantage de travail peut être réalisé en parallèle?
• Comment les leaders en ingénierie peuvent-ils mesurer le progrès lorsque les indicateurs traditionnels de productivité ne racontent plus toute l’histoire?
• Comment rendre les connaissances organisationnelles réutilisables d’un projet à l’autre plutôt que de reconstruire le contexte chaque fois?

Il n’existera pas un seul modèle opérationnel qui fonctionne partout. La bonne approche dépend de l’organisation, de ses systèmes, de son environnement réglementaire, de sa maturité en ingénierie et de sa tolérance au risque. Mais attendre que la technologie se stabilise avant de commencer à répondre à ces questions n’est probablement pas une bonne stratégie non plus. La technologie évolue rapidement, et l’apprentissage organisationnel prend du temps.

Commencer par un seul flux de travail

Devenir AI-native ne nécessite pas une transformation complète du jour au lendemain. Une approche plus utile consiste à développer progressivement ses capacités :

Évaluer. Comprendre le processus de livraison actuel, les outils, les contraintes et la performance de référence.

Cibler. Choisir un flux de travail à forte valeur, avec un résultat clair et un niveau de risque gérable.

Construire. Connecter les agents au contexte, aux outils d’ingénierie et aux mécanismes de contrôle nécessaires pour accomplir le travail.

Valider. Mettre en place des mécanismes d’évaluation, des points d’approbation humaine et des critères de succès mesurables.

Passer à l’échelle. Étendre le flux de travail et augmenter le niveau d’autonomie à mesure que la performance est démontrée.

Cette approche crée une boucle de rétroaction entre les capacités techniques et l’apprentissage organisationnel. Elle permet aussi de faire évoluer la conversation. Plutôt que de demander : « Comment déployer l’IA partout? », on peut poser une question beaucoup plus utile : Où l’IA peut-elle réellement améliorer la façon dont le travail circule dans notre organisation?

L’opportunité va bien au-delà d’un développement plus rapide

La première vague d’IA en ingénierie logicielle a aidé les personnes à réaliser certaines tâches plus rapidement. La prochaine changera la façon dont le travail lui-même est organisé.

Lorsqu’elle est bien mise en place, une approche AI-native peut réduire le temps entre une idée et un logiciel fonctionnel, permettre à davantage de travail d’avancer en parallèle, rendre les pratiques d’ingénierie plus cohérentes, réutiliser les connaissances organisationnelles d’un projet à l’autre et créer davantage de capacité pour l’expérimentation et la modernisation.

Surtout, elle peut donner aux ingénieurs plus de temps pour se concentrer sur les aspects du développement logiciel où le jugement humain compte le plus. Utiliser l’IA devient rapidement un incontournable.

Le véritable travail consiste maintenant à construire les systèmes, les pratiques et les organisations capables de transformer cette capacité en valeur d’affaires réelle.

Par où commencer?

Si vos équipes expérimentent déjà avec l’IA, mais que vous vous demandez quelle devrait être la prochaine étape, c’est exactement le type de problème que nous explorons avec nos clients.

Nous pouvons vous aider à analyser votre processus de livraison logicielle, à identifier où l’IA et les agents peuvent créer le plus de valeur, et à concevoir les flux de travail, les mécanismes de contrôle et le modèle opérationnel nécessaires pour que tout cela fonctionne concrètement.

Contactez-nous pour discuter des endroits où une approche AI-native pourrait créer de la valeur dans votre organisation.

‍