Production logicielle agentique : comment accompagner les équipes ?

Depuis le début de ma carrière, je m’intéresse à l’accompagnement humain des changements technologiques. Avec l’association Retravailler, j’ai accompagné dans les années 1980 des secrétaires et des assistantes de direction dans le passage au traitement de texte. Au CMPC, le moteur d’inférence du Sphinx assiste l’inventaire ; le logiciel collaboratif en ligne, en mode SaaS, transforme la coopération entre musées avec des droits de partage fins. Depuis 2024, j’accompagne l’IA générative auprès de business analysts, de développeurs et de chefs de projet de cinq équipes agiles. À chaque étape, la même question demeure : comment les personnes s’approprient-elles de nouveaux moyens d’agir et font-elles évoluer leur travail ?

L’IA transforme aussi la réflexion sur ce que l’on veut produire. Dans ma salle de rédaction, les lectures proposées par mon agent Sourceur peuvent déplacer la trame d’un article. En production logicielle, explorer un besoin avec l’IA peut modifier le besoin lui-même. Les activités se recomposent : certaines tâches sont déléguées, d’autres demandent davantage de conception et de jugement. Le positionnement des métiers et les responsabilités de chacun doivent être retravaillés avec les équipes.

La production logicielle agentique, où des agents réalisent des tâches enchaînées à partir d’un objectif et d’un cadre, rend ce changement particulièrement visible. Comment accompagner des professionnels expérimentés lorsque leurs gestes et leurs repères évoluent ? Il faut étudier ces déplacements et organiser l’apprentissage dans le travail pour sécuriser les pratiques et rassurer les équipes. L’enjeu est de leur donner prise sur cette transformation.

Ce qui change ou doit changer

Conception, spécifications et validation

Le vibe coding permet de faire évoluer un programme par demandes successives à l’IA. À partir d’une intention métier, un premier prototype donne à ceux qui expriment le besoin quelque chose à essayer et à discuter. Ils peuvent préciser un usage, découvrir une attente différente ou renoncer au besoin initial. Cette maturation peut transformer ce que l’on cherche à construire. J’y retrouve un principe des méthodes agiles comme Scrum : réexaminer le besoin en cours de réalisation et adapter les priorités pour produire ce qui apporte le plus de valeur au métier.

Je retrouve ce mouvement dans ma salle de rédaction. Mon agent Sourceur cherche d’abord dans mes expériences et mes textes, puis complète avec des références externes que je lis et valide. Ces lectures me conduisent parfois à changer la trame initiale ; le dialogue déplace une idée et j’en décide la suite. Le parallèle avec le prototype porte sur cette réflexion qui mûrit au contact d’une production et de nouveaux éléments.

À partir du prototype discuté, l’équipe peut formaliser les spécifications fonctionnelles détaillées, ou SFD, puis les spécifications techniques détaillées, ou STD. Les exigences non fonctionnelles entrent dans ce passage : sécurité avec le RSSI, protection des données avec le délégué à la protection des données, ou DPO, et cohérence technique avec l’architecture. Le développement piloté par les spécifications, ou SDD, propose un support à cette organisation. Dans Spec Kit, GitHub propose de formaliser le besoin, le plan et les tâches avant l’implémentation ; j’y vois une démarche à adapter au contexte.

À mon sens, le vibe coding doit devenir une activité que le business analyst peut mener en autonomie technique pour faire mûrir le besoin. Le développeur approfondit en parallèle la conception et la compréhension du métier. Je retrouve ici la figure du concepteur-développeur : elle rend plus perméable la frontière entre compréhension du besoin et construction de la réponse. L’apprentissage doit permettre ce rapprochement tout en laissant les décisions de validation clairement attribuées.

Les SFD et STD nécessitent une structure lisible par l’humain et l’IA : titres explicites, règles identifiables et critères vérifiables, avec des références cohérentes. Le Markdown convient à cette organisation. En ne transmettant que le contexte utile à l’agent, on peut économiser des tokens. L’actualisation documentaire doit être confiée à un autre agent, sous supervision humaine. L’objectif est de lutter contre l’obsolescence documentaire et d’en améliorer l’utilité au regard de l’effort consenti. Les humains contrôlent la cohérence entre règles, spécifications et logiciel.

Le plan de tests se prépare avec cette formalisation et un agent IA spécialisé. L’humain choisit la stratégie et les méthodes adaptées aux risques. Le pairwise testing, ou test par paires, couvre les combinaisons de valeurs de deux facteurs parmi les paramètres retenus, sans épuiser toutes les interactions possibles. L’assistance de l’agent permet d’approfondir l’usage de telles méthodes. Le testeur contrôle la pertinence des cas et des résultats ; lorsqu’un test échoue, il valide la boucle de correction du code et sa nouvelle vérification.

La revue consacrée à l’IA générative pour l’architecture logicielle cartographie des usages de conception et de validation dans une littérature émergente. J’en retiens l’importance d’arbitrages identifiables. L’architecte, le responsable de la sécurité des systèmes d’information (RSSI) et le délégué à la protection des données (DPO) contribuent à définir les exigences non fonctionnelles et à valider leur réalisation, chacun dans son domaine. L’architecte vérifie la conformité du schéma applicatif ; le RSSI s’appuie sur des agents spécialisés pour les tests de sécurité ou d’intrusion ; le DPO examine les accès aux données personnelles et les risques de réidentification par croisement. Le DPO participe à part entière au travail de l’équipe et garde son indépendance dans sa mission de contrôle. La responsabilité de la conformité reste au responsable du traitement. Le lead technique accompagne l’examen des réalisations. L’automatisation vise à étendre les contrôles ; il faut arbitrer avec pragmatisme leur couverture, le coût en tokens et l’énergie humaine nécessaire.

Le contrôle s’étend à l’exploitation du code produit et à celle des systèmes IA. Dynatrace distingue aussi la surveillance des systèmes IA en production de l’emploi de l’IA pour les opérations : les compétences diffèrent selon l’objet et l’usage. L’enquête SmartBear sur la qualité et les tests relève des préoccupations concernant la fiabilité, l’intégration et la gouvernance des tests autonomes. Ces enquêtes d’éditeurs donnent des points de vigilance contextualisés.

Dans les équipes que j’accompagne, l’effort accru sur les spécifications et les tests donne un contenu concret à cette évolution. L’automatisation doit aussi relever l’exigence de production : tests fonctionnels automatisés et documentation à jour accompagnent une gestion plus rigoureuse de la dette technique et de la sécurité. Nous devons attendre davantage de fiabilité, puis vérifier que les pratiques mises en place y contribuent.

Cette réflexion concerne également la tierce maintenance applicative, ou TMA, et le maintien en condition opérationnelle, ou MCO. L’hypothèse d’une évolution vers un rebuild permanent, une reconstruction continue du logiciel, mérite d’être travaillée avec les équipes. Elle pose une question de compétences et de responsabilités : comment reconstruire, vérifier et exploiter tout en conservant la maîtrise du service ?

Rôles et motivations

Les responsabilités évoluent avec ces gestes. Un business analyst (BA) explore plus directement une idée ; un développeur approfondit le domaine fonctionnel ; un testeur intervient plus tôt sur les critères de validation. La réflexion d’OCTO sur les métiers du produit éclaire cette ouverture. Les auteurs décrivent une semaine collective : après les fondamentaux, deux jours de pratique sur quatre cas d’usage permettent de construire des prototypes ; le groupe prend ensuite du recul et formalise des propositions. Cette exploration des usages aide à se projeter dans l’évolution des métiers.

Pour un professionnel expérimenté, la question est aussi personnelle. Ce qu’il sait bien faire fonde son efficacité et sa reconnaissance. Lui demander de déléguer une partie de la production tout en renforçant son contrôle peut susciter de l’intérêt, mais aussi une interrogation sur sa contribution future. L’étude sur les coûts psychologiques de l’adoption de l’IA en génie logiciel, menée dans une société danoise de services logiciels, décrit des tensions autour de la vérification, de la responsabilité et de l’identité professionnelle. Ce terrain unique ne décrit pas toutes les équipes ; il aide à nommer des sujets qu’un manager doit pouvoir entendre.

L’analyse publiée par l’Anact sur les transformations du travail invite à regarder l’activité réelle et sa régulation. J’en retiens une conséquence pratique : lorsqu’une personne hésite, il faut comprendre la tâche concernée et les conditions dans lesquelles on lui demande de changer. Une difficulté d’accès à l’environnement, un manque de temps ou une responsabilité mal définie appelle une réponse organisationnelle. Une formation supplémentaire à l’outil ne règle pas nécessairement le problème.

La courbe du changement peut ouvrir cette discussion, à condition de rester un repère qualitatif. Cornelis Neet en examine les limites ; Holdsworth et Bridgman retracent les transformations historiques du modèle et critiquent sa lecture universelle et linéaire. Je ne place donc pas un collaborateur sur une étape supposée obligatoire. Les perspectives individuelles, systémiques et liées à l’apprentissage proposées par Scholkmann aident davantage à chercher ce qui empêche d’avancer dans une situation donnée.

Dans mon expérience Capgemini Nantes, entre 2021 et 2024, nous avons construit avec le groupement Capgemini–Inetum au service de la CNAM une organisation One Team, des structures transverses et une académie en ligne, puis avons évolué vers une logique produit. J’y ai travaillé la façon dont un collectif partage ses repères. Cette transformation, antérieure à la GenIA, nourrit ma lecture de l’accompagnement actuel.

Les IA spécialisées élargissent cette réflexion au-delà du code. Dans l’expérience du CMPC, le Sphinx signale des anomalies d’inventaire et suggère des corrections avant validation humaine. Son moteur d’inférence applique des règles expertes ; les modèles génératifs considérés ici reposent sur des réseaux neuronaux, dits connexionnistes. Les mécanismes techniques diffèrent, mais l’enjeu professionnel demeure : comprendre l’assistance apportée et situer le jugement de ceux qui l’utilisent.

Comment accompagner le changement

Je m’appuie sur trois repères : partir d’une activité réelle, apprendre en coopération, puis vérifier l’autonomie acquise. Ils prolongent mes pratiques de formation chez Netapsys et de transformation avec la cible One Team pour la CNAM. Dans le groupement Capgemini–Inetum, deux cultures d’entreprise doivent se mettre en synergie pour apporter à la CNAM une réponse uniforme et de meilleure qualité. Pour la production agentique, ces repères se déclinent dans un dispositif transitoire, ajusté avec les équipes.

Apprendre en binômes transitoires

Chez Netapsys Madagascar, entre 2012 et 2018, j’associais certifications, partage de connaissances et MOOC à un tutorat lors de la prise de nouvelles fonctions. Le chef de projet jouait aussi un rôle de product owner relais, proche de l’équipe, tandis que les équipes approfondissaient leur connaissance des domaines de leurs clients. Cette expérience de formation et autonomie des équipes relie apprentissage technique, compréhension de l’activité et capacité de décision. Elle reste un point d’appui pour l’accompagnement actuel.

Le pair programming offre une pratique de coopération connue : deux développeurs travaillent ensemble sur une même réalisation et confrontent leurs raisonnements. Dans son article sur le développement logiciel à l’ère des agents IA, Bruno Boucard défend la pratique délibérée et le mentorat pour préserver l’apprentissage. Je retiens cette attention à la progression professionnelle, qui doit trouver sa place même lorsque l’outil produit rapidement une solution.

Ce travail en paire ne concerne pas seulement un junior et un senior. Deux développeurs confirmés ou deux seniors peuvent explorer un problème complexe, discuter un meilleur algorithme ou chercher une solution plus sobre. Le temps de réponse, la consommation mémoire et l’écoconception donnent des objets concrets à cet échange. L’intérêt du binôme est alors la confrontation d’expertises ; chacun doit pouvoir expliquer ses choix et examiner ceux de l’autre.

Ce principe de coopération doit s’étendre à des binômes croisés temporaires entre BA et développeur, ou entre testeur et développeur. L’objectif est défini dès le départ : chacun acquiert les compétences qui lui manquent pour exercer son rôle dans la nouvelle organisation. Le binôme prend fin lorsque cette autonomie est suffisante ; il ne doit pas devenir une dépendance permanente.

Pour un BA, l’exploration d’un besoin par un prototype constitue une première situation de travail. Avec le développeur, il apprend à utiliser l’environnement et à comprendre la production de l’agent. L’objectif est qu’il puisse ensuite conduire seul cette exploration avec les utilisateurs, faire évoluer leur besoin et reconnaître les décisions à soumettre aux autres acteurs. Le binôme prépare ainsi son autonomie technique pour le vibe coding.

Le développeur apprend simultanément le domaine fonctionnel. Il demande au BA de reprendre un parcours complet, puis explique les effets possibles d’une modification de variable au-delà de la fonction immédiate. Ce travail rend visibles les dépendances entre règles, écrans et traitements. Le BA apporte son regard métier et le développeur sa maîtrise technique ; chacun approfondit une zone qu’il connaît moins bien.

Une autre situation consiste à reprendre ensemble une spécification que l’agent interprète mal. Le binôme identifie l’ambiguïté, la reformule, puis vérifie la nouvelle production. La démarche SDD décrite par GitHub fournit un support, mais la spécification reste ouverte aux enseignements de la réalisation. Unmesh Joshi, chez Thoughtworks, rappelle que la conception logicielle se nourrit de ce que l’on découvre en construisant. Il faut conserver cette boucle d’apprentissage après la première rédaction du besoin.

Dans un binôme testeur–développeur, l’équipe choisit une fonctionnalité dont les règles sont comprises. Le testeur apprend à lire et modifier le code des tests automatisés, à comprendre leur exécution et à expliquer pourquoi un résultat valide ou invalide le comportement attendu. Le développeur approfondit avec lui les scénarios qui exposent une erreur fonctionnelle. Tous deux doivent pouvoir défendre ce que le test vérifie.

Les architectes, les leads, le RSSI et le DPO ont aussi leur place dans cet apprentissage. Une séance peut porter sur une décision d’architecture ou sur les données et les droits accordés à un agent. L’équipe part d’un choix réel, en explicite le raisonnement et le consigne. La personne qui apprend doit pouvoir retrouver ce cadre et reconnaître les cas nécessitant un arbitrage.

La recherche menée dans un centre d’opérations de sécurité décrit la construction d’outils LLM spécialisés avec les praticiens et leur ajustement à partir de démonstrations et de retours d’usage. Ce terrain éclaire l’intérêt d’un apprentissage lié aux tâches et aux préoccupations des utilisateurs ; son périmètre reste la cybersécurité. Les principes exploratoires de transformation IA proposés par Tavantzis et ses coauteurs associent également coopération, formation et gouvernance.

Pour lancer les binômes, chacun choisit une activité assez limitée pour être comprise et assez réelle pour faire apparaître les difficultés. Le manager réserve le temps nécessaire et convient avec les participants de la progression attendue. À chaque point d’étape, le travail accompli sert à décider de la suite. Le nombre de séances découle de l’apprentissage.

Le responsable d’équipe doit rendre ce temps compatible avec les engagements de production. Demander de livrer comme auparavant tout en formant un partenaire fait porter au collaborateur une contradiction d’organisation. Le ralentissement lié à l’apprentissage est un investissement que l’entreprise doit assumer. Elle peut ensuite vérifier si cet effort améliore la productivité ou la qualité. Le manager précise ce qui peut ralentir et ce qui doit être maintenu, puis reconnaît le travail de transmission.

Il est aussi nécessaire d’identifier un interlocuteur de référence, le champion IA. Il suit l’actualité et la maturité des modèles et des méthodes, les présente aux équipes et construit avec elles les choix à essayer. Son soutien technique aide à résoudre les blocages ; sa présence et ses explications soutiennent la motivation. Face à l’incertitude et à la crainte de voir son métier remplacé, rendre les difficultés discutables peut rassurer et redonner une capacité d’action.

Valider les productions et construire l’autonomie

L’autonomie doit pouvoir s’observer dans une action. Le BA reprend seul une situation comparable, prépare son environnement et explique les limites de son prototype. Le développeur restitue le besoin fonctionnel et examine les conséquences d’une modification. Le testeur adapte un test automatisé et justifie son verdict. Ces critères se précisent avec les intéressés, selon leurs responsabilités et les risques de l’activité.

Cette vérification demande une production réelle et une discussion sur les choix. Une personne peut obtenir une bonne réponse sans comprendre pourquoi elle est correcte. À l’inverse, une difficulté bien diagnostiquée peut révéler un apprentissage. Il faut regarder sa capacité à expliquer, à corriger et à demander de l’aide au bon moment. L’autonomie comprend la connaissance de ses limites.

Je retrouve ici un enseignement du Sphinx au CMPC : dans cette expérience, le professionnel repère des anomalies et examine les corrections suggérées avant de les valider. Entre le moteur d’inférence à règles et les modèles neuronaux génératifs des agents actuels, les techniques diffèrent. Je conserve la nécessité de définir ensemble le travail d’assistance et l’acte de validation dans le processus professionnel.

Dans une chaîne logicielle, les décisions de validation doivent être attribuées explicitement. Qui peut accepter une règle fonctionnelle ? Qui vérifie une conséquence technique ? Qui autorise le déploiement ? L’analyse d’OCTO sur le passage à l’échelle insiste sur le contexte fourni au système, le jugement de qualité et sa maîtrise. Ces capacités doivent être pratiquées avant l’élargissement des usages. Une procédure que personne ne sait appliquer ne constitue pas un contrôle effectif.

Le champion IA suit ces évolutions. Il explique ce qu’une nouvelle version de modèle ou un changement d’agent modifie dans la préparation du contexte et les résultats attendus. Il aide les équipes à conserver et à adapter des cas de référence. L’apprentissage porte ainsi sur une méthode capable d’accueillir les évolutions et sur la capacité à reconnaître un résultat insuffisant.

Un court retour collectif doit être réservé aux essais qui n’aboutissent pas. L’équipe reprend une sortie incorrecte, retrouve l’hypothèse qui la produit et décide ce qu’elle change dans sa méthode. Cette discussion rend le droit à l’essai concret, tout en maintenant l’exigence de validation avant déploiement. Elle aide chacun à demander un appui avant qu’une difficulté devienne un incident.

Cette exigence ne doit pas faire disparaître le coût humain de la transition. Les observations sur les coûts psychologiques de l’adoption et l’analyse de l’Anact invitent à rendre visibles les efforts de vérification. Les retours doivent aussi porter sur ce qui fatigue, ce qui reste obscur et ce qui redonne de la maîtrise. Le manager peut alors ajuster la charge ou l’accompagnement. Une objection précise sur la qualité mérite d’être examinée avant d’être interprétée comme un manque d’envie.

Chez Netapsys, dans la période 2012–2018, je cherchais à faire comprendre un processus de base et ses raisons avant que les collaborateurs l’adaptent au besoin du client ou de la production. Ce principe guide aussi l’accompagnement actuel : partager une méthode explicable, permettre de l’essayer, puis accepter les améliorations de ceux qui l’utilisent. La coopération demande une prise réelle des équipes sur leurs façons de travailler.

La sortie du binôme peut alors être progressive. La personne réalise d’abord l’activité avec un regard disponible, puis la reprend seule dans le cadre convenu. Le soutien reste accessible sans imposer de travailler systématiquement à deux. Les retours utiles alimentent les supports partagés et les échanges de l’équipe. L’académie en ligne de l’expérience One Team me rappelle l’intérêt d’organiser cette transmission collective : un apprentissage individuel devient plus utile lorsqu’il peut être retrouvé et discuté par d’autres.

Comment évaluer et stabiliser

L’évaluation doit rester praticable dans une DSI qui maintient son activité et continue de livrer. Le cadre proposé par DORA part des objectifs et des décisions à éclairer. Je retiens cette entrée : préciser l’amélioration recherchée, puis rapprocher la valeur métier apportée, l’effort nécessaire et la qualité obtenue. L’équipe doit pouvoir comparer des évolutions et préparer le travail à venir à partir de ses situations réelles.

L’évaluation porte sur le travail complet, depuis la clarification du besoin jusqu’à la validation, puis sur les reprises après livraison. Dans mon expérience GenIA, j’observe un gain global d’environ 10 % pour une équipe débutant avec l’IA agentique, avec une accélération du développement et un effort accru de spécification et de test. C’est cette articulation qui guide la lecture du résultat. Le temps gagné sur le code ne représente qu’une partie du gain de l’activité.

L’étude DORA sur les tensions liées à l’IA, fondée notamment sur des réponses d’ingénieurs Google, décrit elle aussi un déplacement du temps vers l’audit et la vérification. Elle rapporte des associations entre adoption, débit et instabilité, sans établir une causalité générale. Je retiens l’intérêt de regarder ensemble délai et qualité : une production plus rapide doit encore être comprise, intégrée et maintenue.

Il faut suivre la fiabilité et les coûts du dispositif. Les sujets de surveillance décrits par Dynatrace et les réserves des praticiens QA relevées par SmartBear incitent à rapprocher les observations des équipes d’exploitation et de test. Le temps de reprise et de contrôle entre dans l’examen des coûts. Le coût d’appel d’un modèle est une composante du choix, à confronter au résultat accepté par l’équipe.

La spécialisation des modèles ouvre aussi des possibilités. Cloudflare présente une chaîne qui confie l’extraction à Clairic, la décision à Clef et la rédaction de la réponse à un troisième modèle. Cet essai d’éditeur, limité à un scénario, éclaire une option d’architecture. Pour nos choix en DSI, je retiens l’inspiration des méthodes agiles : une tâche de référence et des story points calibrés ensemble aident à comparer l’effort et à prévoir. Ce sont des repères locaux ; la valeur métier reste à discuter séparément. Avec la direction, on partage les tendances et leurs hypothèses, sans faire des points un étalon entre équipes ni imposer de refaire systématiquement le travail.

L’évaluation doit enfin revenir aux personnes. Le BA peut-il explorer et spécifier avec davantage d’autonomie ? Le développeur comprend-il mieux les conséquences fonctionnelles ? Le testeur sait-il expliquer et faire évoluer les contrôles ? Il faut croiser ces observations avec leur appréciation du travail. Une méthode qui semble performante mais dont personne ne peut reprendre les décisions reste fragile. Les binômes doivent se terminer lorsque le transfert attendu est acquis, et se prolonger seulement sur les difficultés identifiées.

Stabiliser signifie garder des repères communs tout en laissant évoluer les outils. Dans l’expérience One Team du groupement Capgemini–Inetum au service de la CNAM, entre 2021 et 2024, j’accompagnais avec le collectif un changement progressif du modèle de production. Cette expérience nourrit ma manière d’aborder la capacité à changer de modèle opérationnel. Pour la production agentique, l’équipe partage les critères de qualité et réexamine régulièrement les pratiques.

Je reste convaincu du potentiel de gains supplémentaires avec la maturité des IA, l’évolution des processus et leur appropriation humaine. Pour avancer, nous devons pouvoir comparer, voir une évolution et alimenter l’amélioration continue. Avec les équipes, on examine ce qui s’améliore dans la durée et les difficultés qui persistent, pour ajuster nos prévisions et décider du pas suivant.

Conclusion

Un BA ou un développeur expérimenté a construit une expertise, des repères de qualité et une manière efficace de travailler. Sa reconnaissance y est souvent attachée. Revoir sa façon d’analyser, de spécifier, de coder et de contrôler demande du temps, des essais, de l’énergie et une réelle remise en question. Une formation à l’outil ne couvre qu’une partie de ce changement.

Mes expériences de formation chez Netapsys, de transformation collective avec One Team dans le groupement Capgemini–Inetum au service de la CNAM, puis d’accompagnement de la GenIA nourrissent cette méthode. Les équipes doivent pouvoir se l’approprier, la tester et l’adapter dans la production agentique. Les bénéfices doivent devenir perceptibles dans leur activité, leur autonomie et leurs perspectives de carrière.

Le rôle du manager est de donner du temps, des méthodes, un environnement d’essai et un soutien accessible, en restant pragmatique et en acceptant que les limites soient discutées. Nous devons commencer maintenant, progressivement, sans attendre une stabilité parfaite des outils IA. Quelle activité choisir avec votre équipe pour apprendre ensemble, vérifier le résultat et décider du pas suivant ?

Sources utiles

Thoughtworks — The Learning Loop and LLMs

universités — Generative AI for Software Architecture

DORA — Balancing AI tensions

OCTO — Le développement logiciel à l’ère des agents IA

OCTO — De l’expérimentation au passage à l’échelle

DORA — Choosing measurement frameworks to fit your organizational goals

OCTO — Une semaine pour appréhender l’IA générative dans les métiers du produit

GitHub — Spec-driven development with AI: Get started with a new open source toolkit

universités — The Psychological Costs of Artificial Intelligence Adoption in Software Engineering

Cloudflare — Introducing Clairic, a new System One class of extraction models

universités — A Sociotechnical, Practitioner-Centered Approach to Technology Adoption in Cybersecurity Operations: An LLM Case

Dynatrace — The State of SRE and Platform Engineering 2026

SmartBear — The State of Software Quality and Testing 2026

Pascal — Capgemini Nantes

Pascal — Netapsys Madagascar

Pascal — CMPC

Anact — L’IA générative au travail : quelles transformations à l’horizon ?

Aalborg/Chalmers — From Challenge to Change: Design Principles for AI Transformations

coachmap — Doit-on faire le deuil de la courbe du changement ?

Scholkmann — Resistance to (Digital) Change: Individual, Systemic and Learning-Related Perspectives

Holdsworth/Bridgman — From coping with dying to coping with organizational change: the bricolage of the change curve’s evolution

Pascal Ravoninjatovo Vila / Pascal Vila — Ma salle de rédaction : collaboration humain–IA sous décision humaine

Site Pairwise.org, maintenu par jaccz ; ressource primaire de présentation et d’orientation vers outils — Pairwise Testing — Combinatorial Test Case Generation