L’IA transforme le développement en travail de vérification. Qui valide ?

Seulement 6 % des développeurs se sentent significativement soulagés par l’IA. 67 % décrivent des journées plus denses, avec un rendement accru. Le dividende n’a pas disparu. Il s’est transformé en une tâche qui n’apparaît dans aucun plan : le contrôle. Personne n’a pourtant décidé qui en est responsable.

Articles associésL’IA ne remplace pas les emplois, elle remplace les profils  /  IA locale : la gouvernance avant l’achat de matériel

Là où l’on décide du déploiement de l’IA, les questions qui reviennent sont : « Que gagnons-nous ? » et « Comment accroître la productivité ? » Le déploiement est financé, les licences sont actives, la rentabilité est promise. Un jour, il faudra bien la montrer, cette rentabilité.

En juin 2026, l’association Python Software a interrogé la communauté PyCon-DE. 383 développeurs, data scientists et ingénieurs en IA ont répondu. Sur les plus de 1 000 réponses reçues, aucun ne signale de suppression de postes concrète due à l’IA. Là où des pénuries de personnel sont signalées, près d’un tiers évoque précisément le développement logiciel classique. Le dividende existe donc. Mais pour l’équipe, il se traduit par une attente accrue. Il ne crée pas de capacité libre pour autant.

Le travail ne disparaît pas. Il change de nature.

96 % des professionnels utilisent des outils d’IA au moins plusieurs fois par jour. Ce qui se délègue ? Tout ce qui peut l’être : la génération de nouveau code (76 %), la recherche (44 %), le refactoring (35 %). Mais qu’en est-il des tâches émergentes ? Pour 68 % d’entre eux, il s’agit désormais de vérifier et de curer les résultats produits par l’IA. Les compétences qui prennent de la valeur ? La maîtrise des domaines techniques, la conception des systèmes et la communication des exigences. Autrement dit, celles qui exigent un jugement humain.

La substitution s’opère, mais à l’échelle des activités, non des postes. La production cède la place au contrôle. Et ce contrôle n’a rien d’une tâche fastidieuse : il prend du temps, demande un esprit critique et engage la responsabilité. Un code ne se parcourt pas en diagonale : ses ramifications ne se révèlent qu’au dernier chapitre.

Or, cette activité de contrôle n’apparaît dans aucun plan. Elle n’est ni identifiée ni budgétée. 16 % des répondants se sentent submergés à la fin d’une journée d’utilisation de l’IA, et ce chiffre atteint un sur cinq dans les grands groupes. La planification de la vélocité ne prévoit aucune ligne pour ce travail. Et comme personne ne s’en porte garant, la responsabilité des erreurs retombe sur le dernier maillon de la chaîne : celui qui clique sur « Merge ».

Plus l’entreprise est grande, plus le rendement diminue

On pourrait croire que ce problème ne concerne que les petites structures désorganisées. C’est l’inverse. Plus l’entreprise grandit, plus la part du travail de contrôle augmente : elle passe de 64 % pour les structures de moins de 50 salariés à 76 % pour celles de plus de 5 000. L’ambiguïté des responsabilités suit la même courbe et, dans les grands groupes, elle constitue le principal goulot d’étranglement, devant la qualité des données, les systèmes hérités et la cybersécurité. Pourtant, les gains d’automatisation ne suivent pas cette tendance : dans les petites structures, plus d’un tiers automatise plus de la moitié des tâches routinières, contre seulement un cinquième dans les grands groupes.

Les grandes entreprises récoltent donc un rendement moindre pour une charge de contrôle bien plus lourde. Et la taille ne protège pas non plus en cas de litige. Environ sept répondants sur dix issus d’organisations de plus de 5 000 salariés estiment que la responsabilité d’une erreur causée par l’IA n’est pas clairement définie et repose, en pratique, sur le développeur ayant intégré le code. Dans les structures de moins de 50 salariés, ils sont tout aussi nombreux. Les services conformité, révision interne ou comité d’entreprise n’y changent rien. Un cadre documenté avec obligation de revue, validation nominative et traçabilité d’audit n’existe que dans 14 % des grands groupes. Et 9 % ignorent même s’il en existe un.

La même machine écrit le code et fournit le signal de qualité

Environ un participant sur six a également décrit un incident concret. Les rapports révèlent un schéma coûteux : le signal de test provient lui-même de la machine.

Un cadre senior dans un groupe énergétique examine une pull request générée par l’IA et est impressionné par une méthode de test élégante. En relisant, les tests n’ont aucun sens, bien qu’ils soient passés au vert. Dans un groupe logistique, l’agent modifie le test en échec à répétition jusqu’à ce qu’il réussisse. L’erreur n’est détectée qu’au moment du déploiement, et la recherche de la cause prend des jours. Dans le secteur pharmaceutique, après six mois de développement piloté par l’IA, on découvre 23 000 lignes de documentation générée que personne n’a lues. Tous les tests sont au vert. Ils vérifient des exigences générées par l’IA contre du code généré par l’IA. Les trois rapports proviennent d’organisations employant plus de 500 salariés.

« Il arrive souvent, lors de la génération de code, que des versions de packages soient tout simplement inventées. Si l’on y croit aveuglément, on se retrouve rapidement dans un tourbillon d’hallucinations et de débogage à l’endroit totalement erroné. »
– Réponse libre issue de l’enquête, juin 2026

L’hallucination, c’est-à-dire une sortie du modèle formulée de manière plausible mais totalement inventée, n’est pas une erreur de débutant. Elle touche des développeurs seniors dans des groupes. Et elle les touche là où les organisations se croient protégées : 90 % vérifient la sortie de l’IA par une revue manuelle, 76 % exécutent des tests. Seulement 30 % disposent d’une évaluation formelle, c’est-à-dire d’un jeu de tests versionné permettant de mesurer si un système résout une tâche de manière fiable. 14 % se fient majoritairement à leur intuition. Pourtant, la confiance dans les résultats a augmenté chez 58 % d’entre eux.

Quatre niveaux agissent de manière plausible. Personne ne prend de décision.

Les personnes interrogées citent en premier lieu des responsabilités floues (40 %) comme principal goulot d’étranglement, suivies par la sécurité, la protection des données et l’AI Act européen (36 %). Ce constat est d’autant plus remarquable que personne ne se comporte de manière inappropriée : chaque niveau agit de manière compréhensible selon sa propre perspective. Pourtant, la décision reste dans le vide.

Chaque niveau peut légitimement supposer qu’un autre en est responsable.

Ces quatre questions en suspens forment ensemble l’écart des signatures. Il s’agit de l’espace entre les niveaux. Aucun d’eux ne commet d’erreur. Seul le développeur qui reprend le code généré ne peut pointer du doigt un autre niveau. Si vous ne pouvez répondre qu’à l’une de ces quatre questions, répondez à la deuxième. Elle est la seule à être tranchée chaque jour dans votre entreprise, même si c’est de manière inconsciente.

Le coût de cette situation est illustré par le rapport le plus alarmant de l’étude : dans une petite maison de logiciels, des failles de sécurité majeures issues d’une utilisation intensive de l’IA n’ont été détectées qu’après le départ du collaborateur concerné. Résultat : un développement complet de novo. Lorsque les connaissances en matière de contrôle et la responsabilité de validation reposent sur une seule personne, une partie de la capacité de contrôle quitte l’entreprise avec elle. Les dommages persistent.

Le délai est repoussé. Pas la responsabilité.

Une partie essentielle de la pression réglementaire temporelle vient de s’atténuer. Fin juin 2026, le Conseil de l’UE a définitivement adopté le Digital Omnibus : les obligations relatives aux systèmes à haut risque selon l’annexe III sont reportées de 16 mois au 2 décembre 2027, et celles concernant l’IA dans les produits réglementés au 2 août 2028. L’annexe III concerne l’IA qui participe à des décisions dans des domaines tels que les crédits, les candidatures ou les infrastructures critiques. Les exigences de fond, elles, restent inchangées.

Beaucoup y voient un signal de relâchement. Moi, j’y lis autre chose. Pour une partie des obligations à haut risque, l’horloge réglementaire ralentit. Mais l’horloge opérationnelle, elle, continue de tourner. L’erreur qu’un agent inscrira dans votre production la semaine prochaine n’attendra pas Bruxelles. La responsabilité opérationnelle naît avec la validation. Et les validations ont lieu quotidiennement chez vous, à 90 % via un examen manuel effectué par un seul individu dont le nom n’apparaît dans aucun procès-verbal.

Qui interprète ces 16 mois comme un report les perd. Qui les considère comme une fenêtre de préparation construit une structure de contrôle sans pression temporelle. Un modèle de responsabilité qui fonctionne au quotidien se construit dans des mois calmes. Sous la pression des délais, on crée un tableau que personne ne mettra à jour.

Trois décisions que vous ne pouvez pas déléguer

Valeur empirique issue de la pratique, non mesurée dans l’enquête : une page suffit jusqu’à environ 500 collaborateurs. Au-delà, il faut un propriétaire désigné par domaine, sinon on assiste à une centralisation théâtrale.

Le contrôle n’est pas un poste de coût

L’enquête fournit une mission de conception. Les données ne justifient pas de supprimer des postes de développeurs. Elles invitent à affiner les profils et à clarifier les responsabilités. Seuls 4 % des répondants estiment que leur travail est dévalorisé. Ce qui pèse sur eux, c’est la solitude de la validation.

Le dividende ne disparaît pas parce que la technique sous-performe. Il se perd dans un travail que personne n’a commandé : invisible, donc non planifié, donc non rémunéré. Et comme personne ne l’a commandé, personne ne s’en sent responsable. Sauf l’individu qui valide. La souveraineté consiste à reconnaître le travail de vérification comme une tâche à part entière et à lui donner un nom avant que le hasard ne le fasse à votre place.

Foire aux questions

Source de l’image : générée par IA (juillet 2026). Diagrammes : Python Software Verband.