Retour d’expérience d’un vieux fan de science-fiction sur l’intelligence artificielle de 2026

 Retour d’expérience d’un vieux fan de science-fiction sur l’intelligence artificielle de 2026

 

Préambule inutile, donc indispensable...

A côté des émissions de variétés insupportables, il y avait dans les 70’s sur la TéVé française une série de SF qui captivait les minots : Cosmos 1999 (et aussi “L’homme qui valait 3 milliards”, mais y avait pas d’ordinateur, donc hors sujet). Ce qui était fascinant dans cette série, en plus des maquettes de vaisseaux spatiaux, était l’ordinateur aves ses loupiottes multicolores qui répondait à tout ou presque sur un ticket de caisse de supermarché. 

Voilà ce que promettait le futur : des machines qui pouvaient résoudre tous les problèmes. Ou presque.

Et maintenant, en ce deuxième quart du XXIème siècle pour nous, informaticiens ?

Les Grands Maitres d’Echecs peuvent se faire plier, idem les meilleurs joueurs de Go. Allons directement au cœur de ce billet.

Chat GPT il y a 3 ans peinait à me sortir une macro Excel d’une demi-page.

Mais c’est déjà la préhistoire.

J’ai depuis le début de l’année un ami sur qui je peux compter : Claude.  (Et je ne suis en aucune manière affilié à Anthropic, au contraire, je paye de temps en temps un forfait mensuel.)

Cas de test : analyse de complexité de code

Voici donc comment Claude m’a aidé lors d’une mission d’audit de qualité de code.

La tentation première aurait été de demander à Claude d’analyser chacun des sources. Avec environ 2 000 programmes, il y a de quoi faire exploser les compteurs. Donc mauvaise pioche.

Le plus efficace est de décrire COMMENT analyser un source. Et c’est ici qu’intervient l’art et la manière d’écrire un prompt (un peu) et de discuter avec l’IA.

Une expérience datant de 27 ans m’a introduit à la complexité cyclomatique des programmes. L’inventeur du concept est Thomas McCabe dans les 70’s (on y revient !) : https://fr.wikipedia.org/wiki/Nombre_cyclomatique

J’ai donc commencé par présenter à Claude le but du projet : 

• “analyser la complexité d’un ensemble de programmes suivant la méthode McCabe pour avoir une vue d’ensemble d’une application d’entreprise.”

• “est-ce que les métriques McCabe sont pertinentes pour analyser du code RPG III et RPG IV ?”

• “quelles sont les autres métriques utiles dans ce cas d’usage ?”

Le premier prompt doit cadrer le sujet, certes, mais ne pas hésiter à engager un dialogue préparatoire avec l’IA pour poser les bonnes bases.

En l’occurrence mon intuition McCabe était bonne.

Et la suite ?

Après avoir fixé les critères discriminants (nombre de lignes, de commentaires, repérages des faux commentaires, nombre de “IF”, de “GOTO”, de sous-routines,...), j’ai demandé à Claude de générer des programmes pour analyser les sources en local ou sur le serveur.

Python est visiblement le langage qu’il connait le mieux. J’ai récupéré autant de programmes Python qu’il y avait de langages à analyser (RPG III, RPG IV et CLP). La syntaxe était suffisamment simple pour que valide les programmes en quelques minutes.

Télécharger les sources sur le PC a pris plus de temps que la génération et la relecture des programmes Python !

L’exécution des programmes une poignée de minutes, et hop ! Le résultat dans un tableau Excel.

J’ai pris ensuite quelques sources analysés pour aller vérifier “moi-même personnellement” les métriques. 

Le reste n’a été que mise en forme des tableaux Excel avec tableaux et graphiques croisés dynamiques.

La suite avec la construction d’un modèle d’estimation de développement

Une cartographie de complexité cyclomatique seule n’apporte qu’un bilan qualitatif. Elle devient réellement puissante quand on y ajoute un modèle d’estimation de développement.

On va raisonner par type de maintenance :

• Maintenance légère (1 à 5 règles de gestion)

• Maintenance moyenne (5 à 10 règles de gestion)

• Maintenance lourde (Plus de 10 règles de gestion)

Croisée avec la complexité des sources pour avoir le nombre de jours de développement sur le source (exemple pas forcément significatif avec ce qui va suivre) :

	Maintenance légère	Maintenance moyenne	Maintenance lourde
Source simple	1 jour	2 jours	5 jours
Source moyen	2 jours	5 jours	10 jours
Source complexe	5 jours	10 jours	Envisager la refonte

J’ai discuté avec Claude sur ces critères, pour affiner le modèle.

Ensuite, je lui ai fourni les tableaux Excel de complexité cyclomatique des RPG III, RPG IV et CLP.

Il m’a généré une page web pour calculer l’estimation de développement :

On recherche le programme, on choisit le type d’intervention

 

Et le nombre de jours estimés apparait