Lorsque le code est produit plus rapidement et que certaines parties du système deviennent moins déterministes, la vérification devient essentielle : c’est le seul moyen de savoir si un système fonctionne. L’idée inverse – » si l’IA écrit un meilleur code, on aura moins besoin d’assurance qualité » – confond deux choses distinctes : la correction syntaxique du code et son adéquation aux besoins de l’entreprise.
Un modèle produit du code qui compile et effectue une action raisonnable. Il ignore cependant si cette action correspond aux besoins de votre entreprise, car cette information ne figure pas dans le code : elle se trouve dans le processus, la réglementation et les exceptions non définies par le système.
Les systèmes actuels combinent des composantes déterministes et probabilistes, chacune étant vérifiée différemment. La confusion entre ces deux éléments est à l'origine de la plupart des problèmes de production.
|
Aspect |
Composant déterministe |
Composante probabiliste |
|---|---|---|
|
Qu'est-ce qui est vérifié ? |
Puisse le résultat être conforme aux attentes. |
Que le résultat soit acceptable assez fréquemment |
|
Résultat du test |
Réussite ou échec |
Distribution de la qualité sur un ensemble |
|
Quand il fonctionne |
Dans chaque changement |
À chaque changement et périodiquement en production |
|
Ce qu'il détecte |
Régressions |
Régressions et dérive comportementale |
|
Qui définit les critères |
L'équipe technique |
Entreprise, avec des études de cas réelles évaluées |
La dernière ligne est la plus importante. En termes de probabilité, le critère de « correction » ne peut être défini par la seule équipe technique, car il dépend de ce que l'entreprise considère comme acceptable : un résumé omettant une information secondaire peut être parfait dans un contexte et inacceptable dans un autre.
C’est pourquoi l’atout le plus précieux d’un projet d’IA n’est ni le modèle ni l’invite : c’est… l'ensemble des cas évalués, avec la réponse que l'organisation juge appropriée pour chaque cas. Cet ensemble de réponses reste stable malgré les changements de fournisseurs, permet une comparaison objective des alternatives et détecte si une nouvelle version a aggravé quoi que ce soit. C'est l'élément qui permet de changer de modèle en toute sérénité.
Lorsque l'équipe écrivait tout le code manuellement, la relecture par les pairs couvrait une bonne partie de la vérification. Avec un volume plus important, cette couverture est diluée : non pas parce que les relecteurs sont moins compétents, mais parce qu'il y a plus de code à vérifier dans le même laps de temps.
Le rapport DORA 2024 a mesuré les conséquences pratiques : l’adoption croissante de l’IA a entraîné une baisse de la stabilité des livraisons de 7,21 milliards de dollars, liée à l’augmentation de la taille des modifications. Par ailleurs, 39,21 milliards de développeurs ont déclaré avoir peu ou pas confiance dans le code généré, ce qui introduit un coût rarement pris en compte : le temps consacré à la vérification manuelle d’un élément censé être un gain de temps.
La solution ne consiste pas à augmenter le temps consacré à la révision. Il s'agit de remplacer la révision manuelle par une vérification automatisée lorsque cela est possible, et de réserver l'intervention humaine à ce que seul un humain peut juger : si le produit répond aux besoins de l'entreprise.
Tests unitaires et intégration. Rien de nouveau sous le soleil, et c'est même devenu plus nécessaire avec l'augmentation du volume de code. Le code doit être écrit, ou du moins relu, par une seule personne : si le même système génère l'implémentation et les tests, on se retrouve dans une impasse.
Ensemble d'évaluation des composants d'IA. Des scénarios concrets, avec les résultats attendus, sont exécutés pour chaque modification de modèle, d'invite ou de configuration. Sans cela, il est impossible de savoir si une mise à jour a amélioré ou détérioré le système.
Preuves d'exceptions. Les rares cas rencontrés dans le processus servent de tests. C'est ainsi que nous nous assurons que le système s'adapte à chaque utilisateur comme il se doit, au lieu d'improviser.
Tests de sécurité spécifiques. Les tentatives d'injection sont immédiatement détectées, l'application de la règle « le composant ne dépasse pas ses permissions » est vérifiée et le composant ne divulgue aucune information confidentielle. OWASP inclut ces vecteurs dans son Top 10 des vulnérabilités pour les applications LLM en 2025.
Vérification continue en production. Un échantillonnage périodique de cas réels, examiné par un humain, est le seul moyen de détecter les dérives : un système peut se dégrader sans qu’une seule ligne de code ne soit modifiée, car le modèle, les données ou le contexte d’utilisation ont changé.
La cinquième couche est celle qui n'existe presque jamais et celle qui prévient le plus d'incidents, pour la raison que nous avons expliquée lorsque nous avons parlé de observabilité et automatisation [lien interne]Sans mesure continue, le signal d'un problème provient du client.
Il ne s'agit pas d'un argument conservateur. Le profil de l'assurance qualité évolue considérablement, et c'est une bonne chose :
Il s'agit de passer de la simple vérification du bon fonctionnement à la définition des conditions nécessaires à ce bon fonctionnement. Cette seconde tâche est plus complexe, plus précieuse et ne peut être automatisée.
Lorsqu'une personne propose de réduire les investissements dans la qualité sous prétexte que « l'IA écrit un meilleur code », la question qui oriente la conversation est : Comment saurons-nous quand il aura cessé de fonctionner ?
Si la réponse est que quelqu'un le remarquera, l'organisation a délégué son contrôle qualité à la patience de ses clients. Si la réponse inclut des tests automatisés, une suite d'évaluation versionnée et un échantillonnage continu en production, alors l'efficacité peut être abordée de manière réaliste.
Non, cela l'augmente. Un modèle produit du code qui compile et fonctionne de manière satisfaisante, mais il ignore si cela correspond aux besoins de l'entreprise, car cette information réside dans le processus et les exceptions, et non dans le code lui-même. De plus, le volume accru de modifications réduit la portée de la revue par les pairs.
L'évaluation d'un ensemble de cas concrets, ainsi que la détermination de leur réponse attendue, pour chaque modification de modèle, invite ou configuration, permettent d'obtenir non pas un résultat binaire (« réussi » ou « échoué »), mais une distribution de qualité. Les critères d'acceptation doivent être définis par les métiers, et non uniquement par l'équipe technique.
Il s'agit d'un recueil d'études de cas réels, assorti des réponses que l'organisation juge correctes. C'est l'atout le plus précieux et durable d'un projet d'IA : il permet des comparaisons objectives entre fournisseurs, la détection des dégradations induites par une nouvelle version et la modification des modèles sans prise de risques inconsidérée.
Cinq : tests unitaires et d'intégration, suite d'évaluation des composants d'IA, tests d'exceptions de processus, tests de sécurité spécifiques (injection d'invites, dépassement des limites d'autorisation, exposition d'informations) et vérification continue par échantillonnage de production.
Oui. La situation peut s'aggraver en raison d'un changement de version du modèle, de données d'entrée ou de contexte d'utilisation. C'est pourquoi la vérification ne peut s'arrêter au déploiement et doit se poursuivre par un échantillonnage périodique examiné par des personnes.
On passe d'une exécution manuelle répétitive à la conception de cas, à la création et à la maintenance de suites d'évaluation, et à l'analyse des résultats en production. On passe de la simple vérification du bon fonctionnement à la définition même de ce que signifie ce fonctionnement.
Comment savoir si votre système d'IA a cessé de fonctionner correctement ? Nous avons conçu la suite d'évaluation, les tests d'exception et la vérification continue de manière à ce que la réponse ne dépende pas d'une réclamation client. Parlons-en →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
