Programmer avec l'aide de l'IA : plus vite, mais pas sans expertise ni assurance qualité

IA et machine learning

L'assistant IA écrit en quelques secondes la structure d'un add-in AutoCAD. Elle paraît convaincante – et appelle une méthode qui n'existe pas dans l'API. Ou bien elle se compile sans erreur et utilise une classe qui lève une exception à l'exécution sous .NET 10. L'IA accélère sensiblement la programmation. Mais c'est toujours quelqu'un qui maîtrise le métier qui décide si le résultat est bon.

Ce qui se déplace

Ebi F. Eilber, gérant de Cadida et actif depuis plus de 25 ans dans le développement CAO, le résume ainsi : la programmation est de plus en plus prise en charge par l'IA. La créativité, l'expertise métier, la compréhension du produit, l'innovation et l'assurance qualité n'en deviennent que plus importantes.

• Créativité : quelle est la bonne solution ? L'IA répond à la question qu'on lui pose – pas à celle qu'on aurait dû lui poser.
• Expertise métier : comment se comporte une référence de bloc, qu'exige une norme, quel est le bruit d'un capteur ? Sans ce savoir, une erreur plausible passe inaperçue.
• Compréhension du produit : de quoi l'utilisateur a-t-il vraiment besoin, et que ne doit-il en aucun cas se produire ?
• Innovation : la nouveauté naît de l'expérience et des idées, pas de la moyenne d'exemples connus.
• Assurance qualité : si le code est produit plus vite, il doit aussi être vérifié plus vite et plus à fond.

Là où l'IA aide aujourd'hui

L'IA convient bien pour les structures et le code répétitif, pour la transformation de programmes existants, par exemple lors d'un portage, pour les cas de test qu'on omet sinon faute de temps, et pour expliquer du code inconnu. Plus une technique est répandue, mieux l'IA la connaît. Avec des API spécialisées comme AutoCAD, Revit ou FeatureCAM, avec des pilotes de périphériques et lors de changements de version, elle devient moins sûre – tout en paraissant tout aussi convaincue.

Là où elle se trompe

Un exemple bien étudié est celui des paquets inventés. Pour une étude présentée à USENIX Security 2025, 16 modèles de langage ont généré 576 000 exemples de code. En moyenne, au moins 5,2 % des paquets recommandés par les modèles commerciaux et 21,7 % de ceux recommandés par les modèles librement disponibles étaient inventés. C'est plus qu'un désagrément : des attaquants peuvent enregistrer ces noms et publier du code malveillant sous ces noms.

Un deuxième exemple est le ressenti personnel. Dans une étude randomisée de METR datant de 2025, 16 développeurs open source expérimentés ont eu besoin en moyenne de 19 % de temps en plus pour leurs tâches avec des outils d'IA – et ont estimé après coup avoir été 20 % plus rapides. METR souligne lui-même que les outils ont évolué depuis et que le résultat ne doit pas être généralisé. La leçon demeure : mesurer plutôt qu'estimer.

L'assurance qualité pour le code généré par IA

• Une revue comme pour un nouveau collègue : chaque modification est relue par quelqu'un qui est responsable du code.
• Les tests d'abord : ce sont les critères de réception et les cas de test qui définissent ce qui est correct – pas l'assistant.
• Vérifier automatiquement : tests unitaires et tests d'interface, analyse statique et contrôles de sécurité s'exécutent à chaque build.
• Confidentialité : le code des clients et les secrets d'affaires ne doivent aller que dans des services d'IA dont le contrat et le traitement des données ont été clarifiés.
• Valider les dépendances : les nouveaux paquets n'entrent dans le projet qu'après vérification. Un petit script dans le build arrête tout ce qui n'est pas validé :

import re

import sys





def paketnamen(pfad):

    """Lit les noms de paquets d'un fichier requirements, normalisés selon PEP 503."""

    namen = set()

    with open(pfad, encoding="utf-8") as datei:

        for zeile in datei:

            zeile = zeile.split("#")[0].strip()

            if zeile and not zeile.startswith("-"):

                name = re.split(r"[\s\[<>=!~;@]", zeile, maxsplit=1)[0]

                namen.add(re.sub(r"[-_.]+", "-", name).lower())

    return namen





neu = paketnamen("requirements.txt") - paketnamen("freigegeben.txt")

for name in sorted(neu):

    print("Nicht freigegeben:", name)

sys.exit(1 if neu else 0)

Ce qui compte, c'est la validation, pas la simple existence d'un paquet. Un nom inventé peut avoir été enregistré depuis longtemps par un attaquant. Et la responsabilité reste là où elle était : le Cyber Resilience Act ne demande pas si c'est un humain ou une IA qui a écrit le code. C'est le fabricant qui répond de la sécurité du produit.

Erreurs typiques

• Reprendre du code généré par IA parce qu'il compile.
• Ne pas vérifier les suggestions concernant des API spécialisées par rapport à la documentation de la version utilisée.
• Installer les paquets proposés par l'assistant sans les vérifier.
• Faire écrire aussi les tests par l'IA et se contenter de vérifier qu'ils sont verts.
• Estimer le gain de temps au lieu de le mesurer.
• Ne plus faire formuler que des requêtes aux débutants. Sans expertise métier, ils ne reconnaissent pas les erreurs.

Sources : J. Spracklen et al., « We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs », USENIX Security 2025 ; METR, « Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity », juillet 2025 ; avis : Ebi F. Eilber, gérant de Cadida Software GmbH.