Les risques de la programmation boîte noire avec l'IA

En QA (assurance qualité) et en test, il est courant de parler de tests en boîte noire ou de tests en boîte blanche. Les tests en boîte noire sont effectués lorsque vous ne connaissez pas le fonctionnement interne du système et que vous testez sa fonctionnalité. Les tests en boîte blanche sont réalisés lorsque vous connaissez le fonctionnement ou la structure interne du système, et les tests sont configurés pour vérifier les différents cas possibles prévus par le code.

Avec les outils d'intelligence artificielle, un phénomène que l'on pourrait appeler la programmation de boîte noire est en train d'émerger. L'utilisateur spécifie à l'IA ce qu'il souhaite obtenir fonctionnellement d'une application, et l'IA la génère.
L'utilisateur ne sait pas comment son application fonctionne en interne, cela ne l'intéresse pas, ou il n'est pas capable de comprendre les implications de la manière dont la solution a été implémentée.
Ce cas de figure est typique de l'utilisation d'outils comme Lovable et d'autres qui commencent à apparaître, mais l'acceptation de code généré par l'IA sans examen ni compréhension mutuelle pourrait également être considérée comme de la boîte noire.

Par opposition à la programmation boîte noire, il existe également la programmation boîte blanche avec l'IA. Dans ce cas, un responsable technique décide de l'architecture, de la manière d'implémenter la solution et s'aide de l'IA pour la coder plus rapidement. En fonction du contexte et de la capacité de compréhension, les morceaux délégués à l'IA sont plus ou moins grands.
Le rôle du développeur de produit change : au lieu d'écrire des lignes de code, il conçoit/dirige, orchestre et révise, devenant entièrement responsable du "comment". C'est pourquoi je recommande que les fragments demandés à l'IA soient suffisamment petits et concis pour pouvoir être relus, compris et pris en charge lors de la maintenance ultérieure (ma recommandation : rien de plus grand qu'une pull request que nous serions capables de réviser et de comprendre). Bien qu'une connaissance absolue soit inaccessible et qu'il existe plusieurs nuances de blanc, la programmation boîte blanche consiste à comprendre la solution le plus complètement possible ; il ne s'agit pas de diviser une grande boîte noire en une multitude de boîtes noires plus petites.

Bien que j'aie évidemment ma préférence, une méthode n'est pas bonne ou mauvaise en soi, il faut simplement les comprendre, analyser leurs forces et faiblesses, et surtout mesurer leurs risques.

Dans le cas de la programmation boîte noire, les risques qu'il conviendrait d'évaluer selon moi sont les suivants :

Risque 1 : Le manque de responsabilité. Comme je le mentionnais dans un article précédent, l'IA ne peut pas conduire à une dilution de la responsabilité. Si le logiciel généré ne fonctionne pas correctement, s'il présente des problèmes de performance, de sécurité, de stabilité ou des effets secondaires imprévisibles, le responsable doit être clairement identifié. Le fait de ne comprendre ni le comment ni le pourquoi de ces problèmes complique grandement l'acceptation de cette responsabilité.
Risque 2 : La perte de contrôle de la qualité. Ne pas savoir comment le logiciel a été généré nous empêche de savoir si le produit final est de qualité ou non. Ce n'est pas nouveau : la plupart des parties prenantes veulent simplement que le logiciel fonctionne, peu importe s'il a été conçu avec rigueur. Mais ceux qui travaillent dans l'architecture logicielle et qui s'y connaissent savent que si la qualité fait défaut, si la dette technique s'accumule, on finit toujours par le payer : difficultés de maintenance, bugs, lenteurs, complexité accrue et, en fin de compte, nécessité de réécrire entièrement le logiciel à partir de zéro.
Risque 3 : Méconnaissance de l'architecture logicielle : Ignorer l'architecture du logiciel implique d'ignorer ses forces et ses faiblesses, de ne pas savoir quelle partie devra être renforcée ou même de quelle manière elle peut ou doit évoluer. C'est aussi ignorer quelles sont ses dépendances et ses vulnérabilités potentielles.
Risque 4 : Performance : La performance d'une application est intimement liée à son architecture. Nous pouvons parler de problèmes d'évolutivité (scalabilité) ou "simplement" d'une utilisation inefficace des ressources, mais sans comprendre comment une application est construite, il nous est impossible d'agir, et encore moins de proposer des optimisations.
Risque 5 : Connaissance implicite : Lorsque nous définissons et implémentons un projet, il existe un contexte et des connaissances implicites apportés par chacun des acteurs, ce qui crée de la valeur. Par exemple, un architecte ou un développeur logiciel apportera son expertise sur l'architecture, les patterns de conception, la sécurité des données, ainsi que sur des aspects fonctionnels issus d'expériences et d'implémentations antérieures. Comme une grande partie de ce savoir est implicite, il n'est ni transmis à l'IA, ni exigé d'elle, ce qui conduit à une solution de moins bonne qualité que si plusieurs acteurs aux compétences variées avaient participé à sa génération.
Risque 6 : Évolution vs révolution (refactoring vs replatforming) : Nous devons garder à l'esprit que le développement logiciel est un processus itératif. On ne conçoit pas une application une bonne fois pour toutes. Elle doit évoluer, être corrigée, améliorée, etc. En ne connaissant pas le "comment", on ne peut pas spécifier l'évolution de certains aspects de manière précise. À la place, on ajoute de nouvelles spécifications de haut niveau, avec un risque très élevé que l'IA réécrive l'existant pour se conformer aux nouvelles demandes, brisant ainsi les fonctionnalités précédentes, recréant des bugs, et faisant réapparaître tous les problèmes liés à la réécriture complète d'un logiciel plutôt qu'à son refactoring.
Risque 7 : Perte d'opportunités par manque de connaissances : Dans certains cas, la connaissance fine de la façon dont un produit est conçu et la maîtrise des capacités technologiques génèrent des opportunités business, de nouvelles options fonctionnelles, etc. C'est ce qu'on appelle le développement de produit "bottom-up" (du bas vers le haut). En occultant cette expertise et en se passant des acteurs qui maîtrisent le fonctionnement interne, on perd cette capacité créative.

En ayant conscience de ces risques, il convient d'être prudent face aux implications de la programmation boîte noire. Néanmoins, comme mentionné plus haut, cette approche n'est pas mauvaise en soi. Il existe des cas où ce type de programmation peut s'avérer intéressant, car il requiert moins de ressources humaines (je ne me prononcerai pas ici sur la consommation de tokens).

Par exemple, pour des preuves de concept (PoC), des pilotes ou des prototypes, cela peut être pertinent. Ce sont en effet des cas où la performance et la stabilité en production importent moins que la vitesse et la capacité à tester des concepts, sans oublier que l'objectif n'est pas de créer un logiciel destiné à durer, à s'enrichir et à évoluer.

En résumé, lorsque nous programmons avec l'IA, tout comme si nous confiions un projet à une société de conseil, nous devons nous interroger sur les implications d'ignorer la nature de ce code, sur les risques que cela comporte et sur la façon dont nous allons le maintenir. Nous devons nous demander si nous commandons un logiciel pour résoudre un problème ou si nous souhaitons véritablement l'implémenter.