Actualités
Tous les quelques années, le secteur du logiciel découvre un outil censé réduire le besoin de programmeurs. Dans les années 1980, c’étaient les langages de quatrième génération et les outils CASE ; dans les années 1990, la programmation visuelle ; dans les années 2000, le développement délocalisé ; dans les années 2010, le low-code et le no-code. Dans les années 2020, c’est le code généré par l’IA.
Ingénierie · Opinion
Tous les quelques années, le secteur découvre un nouvel outil censé réduire le besoin de programmeurs. Le discours est toujours le même, tout comme l’erreur sur laquelle il repose.
Dans les années 1980, c’étaient les langages de quatrième génération et les outils CASE. Dans les années 1990, la programmation visuelle. Dans les années 2000, le développement délocalisé. Dans les années 2010, les plateformes low-code et no-code. Dans les années 2020, c’est la génération de code par l’IA.
Chaque vague arrive avec la même promesse : cette fois, c’est différent. Ce n’est jamais le cas. Comprendre pourquoi importe plus que jamais, car cette erreur devient plus rapide et moins coûteuse à commettre.
L’erreur fondamentale consiste à confondre production de code et ingénierie logicielle. Écrire le code est la partie facile. Comprendre ce que le système doit faire, les raisons de son comportement et ses défaillances sous contrainte : c’est là que se trouve le vrai travail.
L’IA peut générer du code, compléter des motifs et réécrire des fonctions. Mais elle ne comprend pas votre système. Elle ne connaît ni vos contraintes, ni vos invariants, ni vos réalités opérationnelles, ni les raisons historiques de vos choix de conception.
Elle produit un résultat qui semble correct. Ce n’est pas la même chose qu’un résultat correct.
C’est le point que beaucoup préfèrent ignorer. L’IA ne pense pas, ne raisonne pas, ne comprend pas. C’est un système statistique qui prédit le jeton suivant le plus probable à partir de motifs déjà rencontrés.
Il n’y a ni intention, ni conscience, ni compréhension des conséquences. Elle ne peut pas douter d’elle-même, prendre du recul et se demander : « Cela a-t-il réellement du sens dans ce système ? »
Pire encore, elle se trompe souvent avec assurance. Elle génère du code propre, convaincant, bien structuré, qui compile parfaitement, mais viole discrètement des hypothèses, rompt des invariants ou introduit des bugs subtils qui n’apparaîtront qu’en conditions réelles.
L’assurance sans compréhension devient dangereuse lorsqu’on lui accorde une valeur d’autorité.
Ce schéma n’est pas nouveau. Il rappelle la vague d’externalisation qu’ont connue de nombreuses entreprises. Le raisonnement était simple : les développeurs coûtent cher, le code peut être écrit moins cher ailleurs ; il suffit donc de confier le travail à l’extérieur et de recevoir le logiciel terminé.
Le résultat était souvent prévisible : des systèmes fonctionnels sur le plan technique, mais mal compris, difficiles à maintenir et finalement impossibles à modifier sereinement. Le code le moins cher devenait le logiciel le plus coûteux.
L’IA introduit le même risque à une autre échelle. Elle accélère la production de code sans accroître la compréhension.
L’IA n’introduit pas une nouvelle catégorie de défaillance : elle amplifie une catégorie existante. Elle commet les mêmes types d’erreurs que les humains :
La différence tient à la vitesse et au volume. D’où une règle simple que les ingénieurs expérimentés appliquent déjà :
Vous êtes responsable de chaque ligne de code que vous intégrez.
Peu importe son origine : IA, collègue, Stack Overflow, bibliothèque ou votre propre clavier. Si vous l’acceptez, elle relève de votre responsabilité.
Le véritable risque ne tient pas à l’IA elle-même, mais à la manière dont les équipes l’utilisent. La différence est nette :
Le schéma dangereux
Ce n’est pas de l’ingénierie. C’est déléguer la réflexion à une machine qui ne pense pas, ce qui dégrade progressivement l’architecture.
Le seul modèle sûr
L’IA est un outil, pas un décideur ni une autorité. Imaginez un collègue très rapide, parfois utile et parfois complètement dans l’erreur, avec une assurance absolue.
L’effet principal de l’IA n’est pas la diminution des bugs, mais la création plus rapide de systèmes complexes. Or, c’est dans la complexité que les logiciels échouent.
La plupart des problèmes de production ne viennent pas d’erreurs de syntaxe, mais de :
L’IA ne résout aucun de ces problèmes. Elle risque plutôt d’y conduire les équipes plus rapidement.
Chaque génération croit que ses outils supprimeront le besoin d’une ingénierie approfondie. Pourtant, la contrainte n’a jamais été la vitesse de saisie. Elle a toujours été la compréhension.
L’IA améliore la première. Elle ne remplace pas la seconde.
Bien utilisée, elle multiplie puissamment les capacités. Employée aveuglément, elle reproduit ce que l’histoire a déjà montré : de grands systèmes que personne ne comprend et que personne ne veut modifier.
La seule question qui compte
La question n’est pas de savoir si l’IA peut écrire du code, mais si les personnes qui l’utilisent comprennent encore les systèmes qu’elles construisent.
Si oui, l’IA est un avantage.
Sinon, elle ne fait qu’accélérer le chemin vers l’échec.
À découvrir
DataBridge est une plateforme de synchronisation réutilisable qui transfère les données métier d’un environnement de gestion local vers des services HTTP, Microsoft SQL Server ou MySQL. Au-delà d’un export ponctuel, elle établit un lien durable entre des environnements très différents et reste souple même lorsque la structure exacte des données n’est pas connue à l’avance.
FileDropArea répond à un besoin concret : ajouter aux applications Visual FoxPro anciennes une zone de glisser-déposer moderne et simple pour les fichiers, pièces jointes Outlook et liens, sans réécrire leur socle technique. Le résultat est un contrôle ActiveX exposé via COM, fondé sur .NET Framework 4.8 et conçu pour FoxPro 32 bits.
FoxSQL est une passerelle SQL sur TCP/IP pour les données AccountView et Visual FoxPro. Les applications C# utilisent les concepts familiers des bases de données, tandis que le véritable moteur FoxPro continue d’assurer son rôle. Personne n’a à déchiffrer des fichiers DBF à la lueur d’une bougie.
