Catégorie : Informatique Page 1 of 4

L’intelligence artificielle (IA) se fait toujours plus présente, 3 ans après la révélation ChatGPT 3.5. Les promesses autour de l’IA sont aujourd’hui démesurées. Beaucoup d’articles de presse prédisent la disparition de nombreux emplois grâce à ces IAs magiques. Les investissements dans les IAs sont absolument considérables. On assiste même à une pénurie de composants (mémoire RAM et disques SSD notamment) dont les prix ont flambé du fait des capacités de production acquises pour former à marche forcée et à tout prix les prochaines générations d’IAs.

De mon côté je suis un utilisateur assidu de ces IAs. Car elles ont parfois des facultés extraordinaires. Mais elles sont encore très loin d’être infaillibles. Elles continuent d’affirmer énormément de choses fausses avec un aplomb incroyable. Bref, le remplacement des humains par des IAs ou par des agents n’est certainement pas pour demain (ni après-demain manifestement). Les IAs devraient encore rester pour un bon moment de simples outils au services des humains sachant s’en servir intelligemment.

Pour un logiciel écrit en C++, j’avais besoin d’une fonction permettant de formater un nombre à virgule flottante sous forme de chaîne de caractères dans le style français, c’est-à-dire qui utilise la virgule plutôt que le point et qui sépare les groupes de 3 chiffres par des espaces insécables. J’ai proposé cette tâche à différentes IAs afin de les comparer.

J’ai précisé pour ce défi : je compile avec Visual Studio 2026, en mode C++ 23 dans un projet C++/WinUI et en ayant activé l’option de compilation /utf-8.

Ce dernier point s’avère être un sérieux piège. De plus on pourrait penser à un problème simple. C’est au contraire un problème compliqué. Car la STL ne fournit pas ce genre de fonctionnalité en standard. Par ailleurs la gestion des espaces insécables pose problème avec du code C++ compilé avec l’option /utf-8.

Quelques informations sur les comportements.

Gemini 3 Pro a tenté 3 fois avec du code qui ne compilait pas, puis avec un code qui plantait à l’exécution. Et enfin s’est fait piéger par le coup des espaces insécables et du flag /utf-8.

Bref, Gemini 3 Pro a réussi au 6e coup, mais au final avec un code élégant.

Claude Sonnet 4.5 a réussi au 2e coup mais avec un code verbeux. Beau joueur, il reconnaît que la solution de Gemini est nettement meilleure.

Copilot a longuement échoué avant de pondre une solution assez verbeuse.

ChatGPT (5.1 ou 5.2) a commencé par échouer comme les autres avec ce problème d’espace insécable en conflit avec le flag /utf-8. Puis a fourni une solution qui ne compilait pas à cause d’un code déprécié depuis C++ 17. Il a finalement réussi au 3e essai. Mais avec un code verbeux.

Deepseek a commencé par échouer comme les autres, puis a proposé du code qui ne compilait pas avant de sombrer et de promettre en permanence que ses nouvelles solutions allaient fonctionner. Au bout du 6e essai, il a rendu les armes. Un vrai naufrage.

Grok (mode automatique) a dû flairer la difficulté mieux que les autres. Il a mis environ 2 minutes avant de répondre. Non seulement il a répondu correctement (et donc du premier coup), mais il a fourni une réponse bien plus correcte que les autres. Voici sa propre explication claire et nette :

Le fait que je sois le premier à avoir correctement géré les groupes de 3 après la virgule, c’est précisément parce que j’ai bien lu ta contrainte typographique française : en France, on regroupe par trois des deux côtés de la virgule, avec des espaces insécables. La plupart des IA (même les bonnes) se contentent de gérer l’entier et oublient la partie décimale, ou font l’inverse (groupes à gauche seulement).

Donc Grok est bien la surprise.

J’ai redemandé aux IAs (sauf Deepseek) une version respectant toutes les contraintes et ont réussi rapidement.

Au final le code de Gemini apparaît concis et limpide. Contrairement à tous les autres. Grok, lui-aussi beau joueur, reconnaît que Gemini mérite pour ça une première place ex æquo ou très légère avance.

Voici donc le classement:

1/🥇 Gemini (solution claire, efficace, mais laborieux)
1/🥇 Grok (fonctionnel du premier coup, mais solution ultra verbeuse)
3/🥉 Claude (plusieurs itérations nécessaires)
4/🏅 Copilot & ChatGPT (nombreuses itérations nécessaires)
5/💥 Deepseek (naufrage et abandon)

Le traditionnel Advent of Code se termine déjà en ce 12 décembre 2025.

Mais on aura quand même eu droit à des exercices intéressants par exemple celui sur les tachyons ou celui concernant la recherche conditionnelle dans l’exploration de graphes basés sur des dictionnaires.

Votre PC qui marchait très bien jusque là vient de passer sa limite de garantie et se met tout à coup à ramer ?

Vous regardez alors le gestionnaire de tâches et vous voyez qu’effectivement la mémoire est saturée, il y a énormément d’applications actives, mais aucune ne semble vraiment fautive. Et donc impossible de comprendre le problème.

Il est temps d’utiliser un outil plus efficace : process explorer. Voici ce que ça donne sur un cas récent :

ServiceShell.exe est un service créé par l’entreprise Dell. Il est utilisé pour les mises à jour automatiques, les diagnostics et le dépannage des ordinateurs Dell. Mais il est surtout connu sur Internet pour ses fuites de mémoire.

Ici, la particularité est que l’on ne peut pas diagnostiquer cette fuite de mémoire avec le gestionnaire de tâches de Windows. Dans mon exemple, on ne voit la fuite de 37 Go qu’en utilisant le process explorer.

On pourrait donc blâmer Windows qui a un gestionnaire de tâches incomplet. Mais au moins il existe des outils permettant de détecter quels logiciels font n’importe quoi.

Après m’être occupé de ce ServiceShell, mon PC a retrouvé sa performance d’origine.

13 mois après mon article Les erreurs de ChatGPT et autres IAs il est temps de faire un point sur la situation car dans le domaine des Intelligences Artificielles génératives, car ça bouge vite.

D’abord je vais donner ma propre classification sur les IAs :

1/ Gemini 2.5 Pro
2/ Claude 4.5
3/ ChatGPT 5

Derrière, DeepSeek, Grok et même Perplexity (notamment pour le navigateur Comet) ne sont pas inintéressants.

Il est hélas encore commun de devoir reprendre une IAs sur des fautes basiques. Y compris pour Gemini. Exemple quand il n’arrive pas à compter jusque 7 :

Et ça arrive régulièrement, ici pour un minuscule test permettant de séparer 2 groupes de nombres composés de moins de 10 éléments :

On peut aussi noter le fort caractère de Gemini qui a tendance à ne rien lâcher même devant un monceau d’arguments en sa défaveur. Ce comportement est assez loin de la flagornerie que l’on retrouve chez d’autres IAs :

Malgré tout, que des IAs commettent des erreurs, après tout, ce n’est pas si éloigné du comportement humain.

Le plus intéressant, c’est qu’il me semble que la nouvelle génération commette moins d’erreurs. Tout en étant capable de véritables prouesses dans un grand nombre de domaines. Par exemple, à partir d’une longue description, Claude est parfaitement capable de créer un outil de visualisation ou d’édition d’environ 800 lignes de HTML/CSS/javascript en moins de 20 secondes. Et ça fonctionne du premier coup, ou avec des retouches mineures au 2e/3e coup. C’est vraiment remarquable. Pour des problèmes très complexes, Gemini est souvent d’un grand secours.

Alors, l’humain a t-il perdu la bataille contre la machine ? Revivons-nous une nouvelle histoire comme celle de John Henry ? Est-il futile pour les humains de continuer à programmer ou faut-il laisser les claviers aux IAs ?

La réponse est clairement NON pour le moment. En fait les IAs sont déjà devenues de vrais assistants dans l’industrie logicielle pour améliorer la productivité. Comme je l’ai mentionné avant, coder une interface de quelques centaines de lignes est devenu trivial pour IA. Tout comme créer ou compléter des tests unitaires, aider à la transformation logicielle, etc.

Mais il reste encore des secteurs réservés aux humains : ceux de la pure créativité. En compétition de programmation, les humains restent encore devant, que ce soit sur des exercices d’optimisation ou encore par exemple de Code Golf.

Il faut bien l’admettre, mais l’optimisation des performances logicielles est bien souvent ignorée. De nos jours, cette activité est souvent peu pratiquée, sacrifiée sur l’autel de la simple mise en ligne de nouvelles fonctionnalités à toute allure. Pendant ce temps, les logiciels, en majeure partie peu performants, brassent les octets des processeurs. La faute à des développeurs peu formés, connaissant peu les algorithmes essentiels, les structures de données principales et leur performance, mais aussi à des langages parfois très peu adaptés, et bien sûr le manque de volonté ou même de besoin. Dans un monde qui s’agite – à juste titre – autour de la durabilité, on ne peut qu’être surpris de la situation en cours.

Mais la situation pourrait changer. Les IAs pourraient sérieusement aider à améliorer la situation, selon plusieurs axes d’ailleurs. Certaines des IAs actuelles les plus performantes (Claude 4 ou Google Gemini 2.5 Pro) sont maintenant capables d’être interrogées sur des morceaux de code de plusieurs centaines de ligne, de comprendre leur fonctionnement (et donc de commenter ligne par ligne ce qui est fait) et de proposer des changements parfois pertinents.

Ces mêmes IAs interrogées alors sur la façon d’améliorer les performances vont bien sûr commencer par suggérer de profiler l’application. C’est évidemment la première chose à faire. On peut pas travailler à améliorer des performances sans mesure précise permettant de savoir où focaliser les efforts. Ensuite, les IAs sont capables de faire des propositions, plus ou moins pertinentes et intéressantes, mais le plus souvent à creuser. Leur utilité est donc non négligeable.

Enfin, là où les IAs peuvent se montrer remarquables, c’est dans la phase finale d’optimisation, lorsque tout a été tenté avec un langage taillé pour les performances (tel que C++, C ou Rust) : l’utilisation des intrinsics est souvent le dernier recours, et avec des gains parfois énormes. Les processeurs modernes sont bourrés des ces instructions (voir le cas d’Intel ou d’AMD) que les compilateurs essaient d’utiliser du mieux qu’ils peuvent. Certaines IAs se débrouillent avec une facilité remarquable pour transformer un code classiques et code vectorisé avec ces instructions très peu connues. Y compris savoir jongler avec les processeurs supportant ou non certains groupes de ces instructions (très utile notamment avec les processeurs Intel qui ont abandonné le support de l’AVX-512).

L’utilisation toujours croissante des IAs dans le secteur du logiciel est donc un bienfait au service des logiciels mieux relus, mieux optimisés et plus sobres.

La série Rematch diffusée notamment sur Arte revisite les combats entre l’ancien champion du monde des échecs Garry Kasparov contre les ordinateurs d’IBM Deep Blue puis Deeper Blue. Cette série sympathique montre la tension lors des matchs d’échecs. Elle cherche aussi à montrer l’enjeu du combat entre l’homme et la machine, le tout dans un contexte où les intelligences artificielles génératives efficaces viennent d’apparaître largement il y a à peine 2 ans.

Si le scénario est plutôt acceptable, l’image est travaillée et les acteurs jouent bien. En revanche, côté informatique, notamment côté programmation, il y a – comme d’habitude au cinéma / à la télé – beaucoup à dire.

En effet, l’écran de contrôle de Deep Blue est divisé en 3 zones. La partie gauche montre l’échiquier en cours, la partie supérieure droite affiche la liste des coups des deux camps. Enfin, la partie inférieure droite est animée. Dans la phase de réflexion, on voit tout un texte défiler et qui s’arrête lorsque Deep Blue a choisi con coup.

Ce texte mystérieux qui défile est manifestement du code C++. On voit sur cette capture d’écran notamment une déclaration de la méthode static bool add_pawn_moves(list_t * list, const board_t * board, int to, bool legal, bool stop)

On retrouve le code associé par exemple sur https://fossies.org/linux/gnuchess/src/engine/move_evasion.cpp (voir la ligne 164). Ce code correspond au code source du programme de jeu d’échecs appelé GnuChess.

Bien sûr, faire défiler un code informatique sur cet écran de contrôle est aussi aberrant qu’inutile. Et ce, même si ce code correspond à un programme de jeu d’échecs. Ce programme GnuChess est gratifié d’un score ELO de 2661 en 2023, ce qui est bien sûr un très bon score, mais loin derrière Kasparov avec ses 2800 points ELO et quelques. Ce n’est certainement pas Kasparov qui aurait pu être inquiété par Gnuchess il y a 25 ans.

De nos jours le programme d’échecs ayant le score ELO le plus élevé de nos jours est Stockfish. Son score ELO estimé étant de 3640. Même si les scores ne sont pas directement comparables, Stockfish est tout de même capable de battre largement n’importe quel humain. Sur ce point, le match est plié.

Tous les programmes de jeu d’échecs actuels sont basés sur de l’algorithmique qui a fait ses preuves. À savoir, des opérations de bitboard pour calculer rapidement l’état du jeu après un coup, des tables de transposition pour éviter d’avoir à calculer des coups similaires, des algorithmes de recherche tels que le MiniMax, la recherche arborescente de Monte Carlo, etc. Et parfois même de la véritable intelligence artificielle afin d’évaluer l’état d’un plateau. Hélas, tous ces aspects n’apparaissent pas la série Rematch. On a plutôt droit à un mystérieux programme qui se modifierait lui-même.

On pourrait aussi parler des écrans d’ordinateur qui fluctuent entre écrans cathodiques et écrans plats alors qu’aussi bien en 1996 qu’en 1997, les écrans plats étaient plutôt inexistants.

On pourrait aussi évoquer la présence inappropriée à l’écran de code javascript et d’erreur de compilation C++. Mais c’est une autre histoire.

Une majorité d’articles (de blogues, de presse, de médias) traitant des GPTs actuels choisit son camp : les GPTs sont nuls ou les GPTs sont très bons, s’améliorent très vite et vont prendre tous les emplois. La vérité est probablement entre les deux.

Car les GPTs se montrent actuellement plutôt très performants pour produire des exemples de code source de langages populaires (python, C++, C#, java, etc.) ou même compléter/adapter/corriger du code source pas trop long.

Néanmoins, on retrouve souvent dans ces articles un phénomène nommé hallucination, terme utilisé quand une IA affirme quelque chose de manifestement faux, et avec beaucoup d’aplomb. Ce phénomène est également lié au erreurs de raisonnement, notamment dans le domaine des mathématiques. Ces erreurs sont particulièrement graves. En voici un exemple :

Ainsi, dans un contexte pas spécialement compliqué, ChatGPT est capable d’affirmer que 0 moins 1 vaut 26. Même en reprenant ChatGPT, les discussions suivantes étaient du même tonneau, à savoir une succession d’erreurs manifestes.

Ici j’étais dans un contexte où je demandais à des IAs (Claude, ChatGPT et Gemini) à faire du code golf sur des cas très simples et pour des langages très populaires (C++, Java, C#). Toutes ces IAs ont beaucoup de difficulté avec le code golf. Elles commettent beaucoup d’erreurs de raisonnement, appliquent des méthodes qui ne fonctionnent pas forcément, et en gros, hallucinent. Par exemple en affirmant qu’elles ont réduit la taille de n caractères quand bien même la taille a plutôt augmenté. Je peux quand même classer les 3 IAs précédente dans l’ordre du meilleur au pire : Claude (3.5 Sonnet), ChatGPT (4) et Gemini.

Le code golf n’est pas qu’une question de technique et de connaissance, c’est aussi une affaire de créativité. Une qualité peu présente avec les GPTs actuels, même si parfois j’ai le sentiment que certaines réponses donnent véritablement l’impression d’une étincelle de créativité (notamment avec Claude).

Finalement le code golf peut être utilisé pour évaluer les avancées des IAs. Avec l’arrivée de nouveaux modèle capables de raisonnements, nous pourrons voir si les domaines encore réservés des humains résistent toujours.

Dans la série des idées que l’on aurait pu découvrir un 1er avril sur le ton de l’humour, on découvre dans l’actualité : On peut « coder sans ordinateur, avec un crayon et un papier ». L’idée va même plus loin et suggère de limiter la bande passante sur Internet à 3 Go par semaine et par personne.

Il est toujours surprenant de voir des personnes faisant preuve d’ultracrépidarianisme. Car non, on ne code pas avec un crayon et un papier, excepté pour les rares cas d’apprentissage (et encore) ou d’entretien d’embauche (là aussi, c’est devenu rare). Coder autrement sans ordinateur est un non sens et une perte de temps totale.

Comment qualifier aussi la limitation de bande passante, à l’heure du télétravail, de la vidéo à la demande ou de l’ère dite du « Big Data » ?

Par exemple, télécharger le catalogue astrométrique Gaia DR3 afin de faire des études sur des catégories d’objets célestes, cela représente un total d’environ 10 To. Soit plus de 3400 semaines (plus de 65 années) à raison de 3 Go par semaine. Bref, une idée à oublier d’urgence.

Contrairement à de nombreux langages, C# (mais aussi VB.NET et F#) disposent d’un support pour les tableaux multidimensionnels. Ainsi, au lieur d’écrire :

double[][] a = new double[n][];
for (int i = 0; i<n; i++)
a[i] = new double[n];

on peut écrire :

double[,] a = new double[n, n];

ce qui simplifie un peu l’écriture et a l’avantage d’avoir un tableau parfaitement rectangulaire par opposition à un tableau irrégulier (jagged array en anglais).

On pourrait s’attendre à ce que ces tableaux multidimensionnels soient plus performants que des tableaux irréguliers, puisqu’il n’y a qu’un seul new à faire, et que l’accès aux valeurs résulte d’une simple opération de type a + b * c.

Hélas, ces tableaux multidimensionnels doivent être absolument évités (en attendant que l’équipe responsable des SDK .NET se penche sur ce sujet). En effet, quelques pages parlent de ce sujet :

• https://stackoverflow.com/questions/468832/why-are-multi-dimensional-arrays-in-net-slower-than-normal-arrays
• https://blog.tedd.no/2021/10/07/why-c-multidimensional-arrays-are-slow/
• https://dev.to/vercidium/improving-performance-of-multidimensional-arrays-in-c-4e9b

En étudiant plb2 sur Github qui est un code destiné à étudier les performances de quelques algorithmes pour 25 langages, j’ai voulu étudier la variation de performance pour les différents types de tableaux, notamment, pour le cas de la multiplication de 2 matrices utilisant l’algorithme naïf.

Voici le code de base qui initialise 2 tableaux (de dimension 1000 par 1000) et effectue la multiplication matricielle le tout en utilisant des tableaux irréguliers :

Et le code équivalent avec des tableaux multidimensionnels :

Or, l’écart de performance est d’un facteur d’environ 3 (environ 1300 ms pour le premier cas et environ 4000 ms dans le second cas sur une machine de test en mode Release et .NET 8, sous Windows), ce qui est loin d’être négligeable.

Donc il est préférable se contenter de la syntaxe verbeuse des tableaux irréguliers.