🤖 AI

A Methodology for Investigating AI Patterns Prevalence in Software Repositories

Cet article propose et valide une méthodologie qui combine l'extraction de littérature pour identifier 14 classes de motifs d'IA avec l'apprentissage actif pour mesurer empiriquement leur prévalence et leur précision à travers des dépôts GitHub réels, comblant ainsi une lacune actuelle dans la compréhension de la manière dont les motifs d'IA sont réellement utilisés en pratique.

Auteurs originaux : Srinath Perera, Hasinthaka Piyumal, Frank Leymann, Rania Khalaf

Publié 2026-07-02

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Srinath Perera, Hasinthaka Piyumal, Frank Leymann, Rania Khalaf

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un urbaniste essayant de comprendre comment les gens construisent réellement des maisons dans une ville moderne et bouillonnante. Vous possédez un livre épais de « Designs de Maisons Idéales » (les modèles d'IA proposés par des experts en littérature), mais vous n'avez aucune idée si quelqu'un utilise réellement ces designs dans les vrais quartiers, ou s'ils inventent leurs propres structures bizarres au fur et à mesure.

Ce document présente l'équipe de chercheurs qui a décidé de sortir, de parcourir 100 quartiers de maisons réels (des dépôts de code GitHub) et de découvrir quels « Designs Idéaux » sont réellement utilisés.

Voici comment ils ont procédé, expliqué simplement :

1. Le Problème : Trop d'idées, pas assez de preuves

Des experts ont écrit des centaines de « Modèles d'IA » (des recettes pour construire des logiciels intelligents). Mais personne ne savait si ces recettes étaient réellement cuisinées dans de vraies cuisines. Les chercheurs voulaient passer de la « théorie » à la « réalité ».

2. Étape Un : Nettoyer le livre de recettes

D'abord, ils ont rassemblé 769 « recettes » différentes provenant de livres, de blogs et de documentations. C'était trop désordonné pour être exploité.

L'Analogie : Imaginez avoir 769 noms différents pour « faire un sandwich ». Certains disent « club », d'autres « BLT », d'autres « jambon et fromage sur pain de blé ».
La Solution : Ils ont utilisé un ordinateur intelligent (un LLM) pour regrouper les recettes similaires. Ensuite, des humains ont examiné les groupes et les ont organisés en 14 catégories claires (comme « RAG », « Architecture d'Agent », « Prétraitement », etc.). Cela a créé un menu organisé de 14 plats principaux.

3. Étape Deux : Trouver les « Quartiers » (Communautés de Code)

Ils ne pouvaient pas simplement regarder une seule ligne de code ; ce serait comme juger toute une maison en regardant une seule brique. Ils avaient besoin de trouver des « communautés » de code qui travaillent ensemble.

L'Analogie : Au lieu de regarder les briques individuelles, ils ont regardé les « pièces » de la maison. Ils ont utilisé une carte spéciale (un graphe d'appel) pour trouver des groupes de code qui sont étroitement connectés, comme une cuisine où la cuisinière, le réfrigérateur et l'évier sont tous liés.
La Sélection : Ils ont choisi 100 projets d'IA du monde réel sur GitHub (les « quartiers ») qui étaient populaires mais pas les énormes frameworks fondamentaux (comme TensorFlow). Ils voulaient voir ce que les développeurs typiques construisaient, et non pas seulement les outils géants sur lesquels tout le monde construit.

4. Étape Trois : Le jeu du « Devine et Vérifie » (Apprentissage Actif)

C'est la partie la plus ingénieuse. Ils n'avaient pas de professeur avec le corrigé (données étiquetées) pour entraîner leur modèle informatique.

L'Analogie : Imaginez un étudiant passant un examen sans connaître les réponses.
1. L'étudiant fait quelques suppositions basées sur quelques exemples qu'il a lui-même générés.
2. L'ordinateur regarde les 100 quartiers et dit : « Je suis à 50/50 sur celui-ci, mais je suis sûr de celui-là ».
3. Les chercheurs (les professeurs humains) ne regardent que ceux sur lesquels l'ordinateur est incertain. Ils étiquettent ceux-là, et l'ordinateur apprend de ces exemples.
4. Ils répètent ce cycle. L'ordinateur devient plus intelligent à chaque tour, demandant de l'aide uniquement lorsqu'il est vraiment confus. Cela leur a évité de devoir lire et étiqueter manuellement des milliers de fichiers.

5. Étape Quatre : Compter les Résultats (Avec un filet de sécurité)

Une fois l'ordinateur entraîné, il a scanné les 100 quartiers pour compter la fréquence d'apparition de chaque modèle.

Le Rebondissement : L'ordinateur n'est pas parfait. Il fait des erreurs. Ainsi, les chercheurs n'ont pas seulement donné un chiffre unique (ex: « Le RAG est utilisé 20 % du temps »).
Le Filet de Sécurité : Ils ont utilisé un truc statistique (comme lancer une simulation 20 000 fois) pour dire : « Nous sommes sûrs à 95 % que le nombre réel se situe entre X et Y ». Cela donne un « intervalle de confiance », reconnaissant qu'il existe une marge d'erreur.

Qu'ont-ils trouvé ?

Le Score : Leur ordinateur a obtenu environ 56 % de précision pour identifier quel modèle était utilisé. Cela semble faible, mais rappelez-vous qu'il y avait 8 catégories différentes à choisir. Une supposition aléatoire ne vous donnerait que 11 %. Ils étaient donc 5 fois meilleurs que le hasard.
Les Gagnants : Ils ont découvert que des modèles comme « Prévision avec modèles classiques » et « Prompting Multimodal » étaient très courants.
Les Perdants : Certains modèles, comme « Utilisation d'outils avec les LLM », étaient difficiles à repérer car ils ne laissaient pas une « empreinte digitale » forte dans le code, donc l'ordinateur les confondait souvent avec « rien de spécial » (la catégorie « Aucun »).
Le Problème du « Aucun » : Beaucoup de codes ont été étiquetés comme « Aucun » (aucun modèle détecté). Cela arrivait parce que certains modèles sont subtils, ou parce que le code était trop désordonné pour que le modèle puisse le reconnaître.

La Grande Conclusion

Ce document n'a pas seulement dit « les modèles d'IA existent ». Il a construit une méthode robuste pour prouver à quelle fréquence ils sont utilisés dans le monde réel, même lorsqu'on ne dispose pas d'un ensemble de données parfait pour commencer.

Ils ont montré que :

On peut organiser une liste d'idées désordonnées en une taxonomie propre.
On peut apprendre à un ordinateur à trouver ces modèles en ne demandant de l'aide aux humains que lorsqu'il est confus (Apprentissage Actif).
On peut estimer la fréquence de ces modèles, tout en admettant honnêtement les « marges d'erreur » de nos chiffres.

C'est comme avoir enfin un recensement fiable de l'architecture d'une ville, accompagné d'une note disant : « Nous sommes plutôt sûrs des maisons, mais les petits cabanons sont peut-être un peu flous ». Cela donne aux développeurs et aux chercheurs une base réelle et étayée par les données pour comprendre comment l'IA est réellement construite aujourd'hui.

Résumé technique : Une méthodologie pour l'investigation de la prévalence des motifs d'IA dans les dépôts de logiciels

Énoncé du problème

Alors que les applications d'intelligence artificielle (IA), particulièrement celles exploitant les grands modèles de langage (LLM), deviennent omniprésentes, il existe un besoin croissant de comprendre l'application pratique des motifs de conception (design patterns) de l'IA. Bien que de nombreux motifs d'IA aient été proposés dans la littérature académique et la documentation industrielle (par exemple, RAG, ReAct, frameworks d'agents), leur prévalence et leur importance réelle dans les bases de code réelles restent non validées. La recherche existante en génie logiciel repose souvent sur des benchmarks curatés (comme P-MART ou DPB) axés sur les motifs de conception traditionnels (par exemple, GOF), qui manquent des données nécessaires pour les motifs d'IA émergents. De plus, un goulot d'étranglement significatif existe : la rareté des ensembles de données étiquetés requis pour entraîner des modèles de détection de motifs de niche ou émergents. Cet article aborde le défi de la validation empirique des motifs d'IA en pratique sans ensemble de données annotés préexistants.

Méthodologie

Les auteurs proposent une méthodologie en quatre étapes pour identifier, détecter et estimer la prévalence des motifs d'IA dans les dépôts open-source.

1. Extraction de la littérature et construction de la taxonomie

Le processus commence par l'extraction de 769 candidats de motifs d'IA à partir de 44 sources publiées, incluant des livres, des enquêtes, des articles de praticiens et de la documentation.

Regroupement (Clustering) : Les descriptions de motifs sont converties en plongements de mots (word embeddings) et regroupées à l'aide de l'algorithme DBSCAN pour grouper les candidats similaires.
Raffinement : Un LLM résume chaque groupe pour créer des candidats raffinés.
Catégorisation : Par inspection manuelle, ces candidats sont classés en 14 classes de motifs distinctes, incluant le RAG, l'architecture multi-agents, le fine-tuning de LLM et le MLOps.

2. Collecte de code réel et découpage (Chunking)

Pour valider ces motifs, les auteurs ont constitué un ensemble de données de 100 dépôts GitHub open-source implémentant des applications d'IA réelles. Les critères de sélection ciblaient des dépôts Python avec 250 à 1 000 étoiles afin de se concentrer sur la « couche application » plutôt que sur les frameworks fondamentaux.

Communautés de code : Au lieu d'analyser des fichiers ou des fonctions individuels, les auteurs ont généré des graphes d'appels de procédures pour chaque dépôt.
Méthode de Louvain : Ils ont appliqué la méthode de Louvain pour détecter des « communautés de code » (groupes de méthodes étroitement couplés).
Stratégie de découpage : Chaque communauté de code a été traitée comme un bloc (chunk) unique pour la génération de plongements. Cette approche a été choisnée car le code au sein d'une communauté est susceptible de contenir des motifs complets, répondant ainsi à la sensibilité des plongements aux limites de découpage.

3. Apprentissage actif pour l'entraînement du modèle

Étant donné l'absence de données étiquetées, les auteurs ont employé une approche d'apprentissage actif (active learning) pour construire un classificateur pour les classes de motifs les plus communes.

Bootstrap : Un modèle initial a été entraîné sur des données synthétiques générées par un LLM ( $D_{init}$ ).
Étiquetage itératif : Le modèle sélectionne de manière itérative des points de données de l'ensemble non étiqueté ( $D_{unlabeled}$ ) présentant l'incertitude de prédiction la plus élevée (via l'échantillonnage par marge).
Humain dans la boucle (Human-in-the-Loop) : Ces échantillons incertains sont étiquetés manuellement par des humains. Le modèle est ensuite réentraîné en utilisant une validation croisée à 5 plis.
Modèle d'ensemble : Le modèle final utilise un ensemble de régression logistique, SVC et KNN, pondéré par leurs scores F1.
Gestion des classes : Pour assurer la stabilité, les classes de motifs ayant moins de 5 % des données ou moins de 20 instances ont été fusionnées dans une classe « None » lors des itérations d'entraînement.

4. Estimation de la prévalence avec intervalles d'erreur

Pour estimer la fréquence réelle des motifs tout en tenant compte des erreurs du modèle et du bruit d'échantillonnage, les auteurs ont appliqué :

Inversion de matrice : En utilisant la matrice de confusion normalisée ( $C$ ) dérivée de la validation croisée, ils ont inversé la relation $O_{samp} = C \cdot T_D$ pour estimer la distribution réelle ( $T_D$ ) à partir de la distribution observée ( $O_{samp}$ ).
Simulation de Monte Carlo : Pour quantifier l'incertitude, ils ont simulé des erreurs d'échantillonnage en tirant d'une distribution multinomiale et ont effectué 20 000 itérations pour calculer les intervalles de confiance à 95 % pour les estimations de prévalence.

Contributions clés

Méthodologie robuste pour les domaines à données rares : L'article propose un cadre combinant l'apprentissage actif et l'annotation humaine pour détecter des motifs sans ensemble de données annotés préexistants, répondant à un goulot d'étranglement critique en génie logiciel.
Technique de découpage novatrice : Les auteurs introduisent une méthode utilisant l'algorithme de Louvain sur les graphes d'appels pour identifier des « communautés de code » comme blocs, optimisant la génération de plongements pour la détection de motifs dans du code réel complexe.
Estimation de la prévalence avec bornes : L'application de l'inversion de matrice et des simulations de Monte Carlo fournit des bornes d'erreur utilisables pour les estimations de fréquence des motifs, permettant aux chercheurs d'évaluer la fiabilité de leurs résultats.
Validation empirique : L'étude synthétise 769 candidats en une taxonomie de 14 classes et fournit l'une des premières validations empiriques de la prévalence des motifs d'IA en analysant 100 dépôts open-source.

Résultats

L'étude a analysé 2 442 communautés de code à travers 100 dépôts.

Performance de classification : Le modèle final a atteint 56 % de précision et 55 % de rappel dans une tâche de classification à 8 voies (incluant une classe « None »). Cela surpasse de manière significative la ligne de base de 11 % du hasard.
Prévalence des motifs : L'analyse a confirmé la présence de plusieurs classes de motifs. Par exemple, « Forecasting with Classical Models » et « Multimodal Generative Prompting » figuraient parmi les plus fréquents.
Bornes d'erreur : L'estimation de la prévalence a fourni des intervalles de confiance utilisables pour 5 classes sur 7 analysées. Les classes avec moins d'échantillons d'entraînement (ex: « Tool Use with LLMs ») présentaient des intervalles de confiance plus larges ou des bornes nulles, indiquant une incertitude plus élevée due à une mauvaise classification (souvent confondues avec la classe « None »).
Comparaison avec les travaux antérieurs : Alors que Pandey et al. [23] ont obtenu un score F1 de 0,91 sur des ensembles de données curatés (P-MART), la performance plus faible de cette étude est attribuée à la complexité du code réel par rapport aux segments propres et curatés.

Signification et affirmations

L'article affirme fournir une base robuste pour comprendre comment les motifs d'IA sont utilisés en pratique, un domaine actuellement dépourvu de données empiriques.

Utilité pratique : La méthodologie permet aux chercheurs de confirmer la disponibilité plus large de classes de motifs spécifiques et de comprendre leur fréquence relative. Par exemple, les résultats suggèrent que « Forecasting with Classical Models » et « Multimodal Prompting » sont nettement plus courants que « Agent Architecture » dans les dépôts analysés.
Évaluation de la fiabilité : Les bornes d'erreur proposées permettent aux utilisateurs d'identifier quand les estimations ne sont pas fiables (ex: pour les classes rares) et de déterminer quand de nouvelles itérations d'apprentissage actif sont nécessaires pour améliorer la précision.
Scalabilité : Les auteurs affirment que leur approche est hautement indépendante des motifs d'IA spécifiques et peut être étendue à d'autres domaines (ex: microservices, informatique quantique) ou utilisée pour détecter plusieurs motifs au sein d'une même communauté de code via des distributions de probabilité.

L'article conclut que, bien que les niveaux de précision actuels soient insuffisants pour identifier des motifs spécifiques dans des segments de code arbitraires, la méthodologie comble avec succès le fossé entre les propositions théoriques de motifs et la réalité empirique, offrant une voie vers un génie logiciel piloté par les données pour l'IA.