1 Introduction
Les modèles de langage de grande taille (Large Language Models, LLM) sont des réseaux
de neurones profonds entraînés sur des corpus massifs de textes. Grâce à l’architecture Trans-
former et au mécanisme d’attention, ils peuvent modéliser des dépendances complexes entre les
mots et générer du texte cohérent. Ces modèles, dont GPT-4 de OpenAI et DeepSeek-Coder
de DeepSeek AI, sont capables d’écrire ou de compléter du code source à partir de simples
descriptions en langage naturel.
L’objectif de ce rapport est d’étudier de façon rigoureuse l’apport de deux assistants IA,
ChatGPT (GPT-4-turbo) et DeepSeek-Coder (version 33B), pour la réalisation du Pro-
jet 2 du cours INFO-F-106 : un système de gestion de base de données respectant le format
binaire ULDB, associé à une interface en ligne de commande (CLI). Nous définirons d’abord le
fonctionnement interne des LLM, puis nous présenterons notre méthodologie d’évaluation, les
résultats obtenus phase par phase, et enfin une discussion critique et impartiale de ces résultats.
2 Contexte théorique des LLM
2.1 Architecture Transformer
Le Transformer se compose de blocs empilés d’encoders et de decoders. Chaque bloc intègre
un mécanisme d’attention multi-têtes (self-attention) permettant de calculer, pour chaque mot,
une pondération sur tous les autres mots de la séquence. Cela confère aux LLM une capacité à
capturer les dépendances à longue portée, en contrastant avec les architectures RNN classiques.
2.2 Apprentissage et inférence
Durant l’apprentissage, le modèle est entraîné par autoregressive language modeling : il prédit
le mot suivant dans une séquence. En phase d’inférence, nous utilise cette capacité pour compléter
ou générer du code en fournissant un prompt.
2.3 Particularités de ChatGPT et DeepSeek
– ChatGPT (GPT-4-turbo) : modèle propriétaire d’OpenAI, optimisé pour les dialogues
et la programmation, avec des millions de paramètres et un fine-tuning par renforcement
sur feedback humain (RLHF).
– DeepSeek-Coder : modèle open-source (33 milliards de paramètres) entraîné spécifique-
ment sur des corpus de code et optimisé pour des tâches de génération de code technique.
3 Méthodes
3.1 Choix des phases testées
Le Projet 2 comporte cinq phases techniques :
1. Gestion de fichiers binaires (binary.py).
2. Création et manipulation des tables (database.py).
3. Insertion et récupération conditionnelle d’entrées.
4. Mise à jour et suppression d’entrées (gestion des reliquats).
5. Interpréteur CLI ULDB (uldb.py).
Nous avons fourni à chaque IA les mêmes instructions précises (prompts) décrivant la signature
des méthodes à implémenter. Chaque phase a été testée de manière indépendante et validée via
une décomposition du jeu de tests fourni pour le projet.
1
3.2 Critères d’évaluation
Pour chaque phase, nous avons évalué :
– Exactitude fonctionnelle : conformité aux spécifications binaires ULDB et aux signa-
tures.
– Qualité du code : lisibilité, commentaires, modularité.
– Capacité d’autocorrection : réaction à un prompt de correction en cas d’erreur.
– Performance : complexité algorithmique et efficacité des opérations (notamment gestion
du string buffer).
3.3 Déroulement expérimental
Chaque phase a été abordée en deux itérations :
– Demande initiale du code (prompt complet).
– Feedback et demande de correction ou d’optimisation si nécessaire.
Le code final validé a ensuite été intégré au projet global pour tester l’intégration et le bon
passage de l’ensemble des tests automatiques.
4 Résultats
4.1 Phase 1 : Gestion de fichiers binaires
ChatGPT a produit une implémentation BinaryFile couvrant la lecture/écriture d’en-
tiers (write_integer, read_integer) et de chaînes (write_string, read_string). Le support
du little-endian et du signe pour les entiers a été correct dès la première version. Un ajuste-
ment mineur a été nécessaire pour la méthode get_size, corrigée en une instruction unique
file.seek(0,2) puis file.tell().
DeepSeek-Coder a renvoyé un code plus détaillé sur les tampons binaires, mais avec une
confusion initiale entre la taille des entiers signés sur 2 bytes vs 4 bytes. Après clarification, le
modèle a produit une version correcte.
4.2 Phase 2 : Gestion basique des tables
La création des tables a exigé la génération du header ULDB, du string buffer initial (16
bytes) et du entry buffer.
ChatGPT a structuré une classe Database avec des méthodes create_table, delete_table,
get_table_signature et list_tables. Les exceptions ValueError en cas d’erreur de création/-
suppression ont été bien gérées.
DeepSeek-Coder a produit une version fonctionnelle mais manquait la gestion de l’extension
".table" dans list_tables. Après prompt, le modèle a ajouté cette condition.
4.3 Phase 3 : Insertion et récupération
Pour l’ajout add_entry, ChatGPT a correctement implémenté l’auto-incrément de l’id et
l’écriture dans l’entry buffer avec double chaînage. Les méthodes get_entry, get_entries,
select_entry et select_entries ont été générées selon la spécification.
DeepSeek-Coder a initialement écrit get_entries sans filtrer le tuple retourné pour un unique
champ ; il a fallu ajouter une condition spéciale pour renvoyer un scalaire au lieu d’un tuple.
2
4.4 Phase 4 : Modification et suppression
ChatGPT a détaillé une gestion de la liste des reliquats, en utilisant le pointeur dédié dans
le mini-header. Sa méthode update_entries vérifiait la capacité du string buffer avant écriture
et réaffectait l’espace si nécessaire. La méthode delete_entries n’assurait le recalcul de la
proportion d’entrées effectives et ne réencodait pas la table si le seuil de 50% était dépassé.
Après plusieurs feedback, il n’a toujours pas pu gérer ce problème. Cette fonctionnalité a du
être codé à la main
DeepSeek-Coder a proposé une suppression simple par réécriture de la liste chaînée, sans
compaction du fichier. Après feedback, il a ajouté la logique de réencodage lorsque nécessaire.
4.5 Phase 5 : CLI ULDB
ChatGPT a généré un parseur basé sur des expressions régulières pour chaque instruction
ULDB. La distinction mode script/ interactif, la gestion des erreurs (DB non ouverte, table
inexistante, types invalides) et l’affichage précis ont été implémentés.
DeepSeek-Coder, plus minimaliste, a fourni un prototype fonctionnel utilisant la bibliothèque
argparse pour le mode script et un simple input() loop pour l’interactif, mais sans gestion
complète des erreurs. Le prompt de robustesse a permis d’améliorer ce point.
5 Discussion critique
Les deux modèles ont montré des compétences solides, mais :
– ChatGPT excelle dans la compréhension globale et la structuration modulaire du code,
ainsi que dans la gestion des retours d’erreurs et la documentation interne. Sa prédisposition
au dialogue facilite l’itération.
– DeepSeek-Coder est très performant pour la production de code bas-niveau et l’optimi-
sation des opérations binaires, mais nécessite des prompts de correction plus détaillés pour
atteindre la robustesse attendue.
– Les IA ne remplacent pas la relecture humaine : la validation des cas limites et des tests
reste un travail essentiel.
Nous arrivons à voir assez distinctement après notre analyse que dans l’ensemble, ChatGPT,
pour arriver au résultat nécessite moins de prompt tandis que DeepSeek a besoin de plus d’ac-
compagnement pour réaliser les même tâches. En outre il s’avère aussi que DeepSeek a tendance
à nous produire des bouts de codes beaucoup plus bas niveau que ChatGPT. Cela pourrait être
un avantage quand on sait que dans le projet il nous a été demandé de travailler au niveau
binaire.
6 Conclusion
Au terme de notre analyse, nous avons pu ressortir le fait que l’utilisation des IA dans nos
travaux de programmation aujourd’hui est vraiment d’une grande utilité productive car elles
nous permettent de gagner énormément en temps, la preuve en est que le projet nous ayant pris
initialement 3 jours avec un régime moyen de 4-5 heures de travail par jour, a été réalisé en moins
de 10 heures grâces aux IA. Ce gain en productivité n’est donc pas négligeable.
Nous pourrions peut-être penser que pour gagner encore plus en productivité nous aurions
tout simplement pu envoyer le pdf entier contenant la description textuelle du projet. C’est ce
que nous avons fait mais nous nous sommes rendu compte que la première version donnée par
chaque IA était assez proche du résultat attendue sauf pour la création du fichier database.py
ou aucune des IA n’a réussi même après de multiples prompts à avoir un code prêt à l’emploi
avec même des erreurs de compréhension de la structure des tables dans le système uldb. Une
3
très longue session assez profonde de programmation à la main s’en est suivie pour normaliser
les fichiers de code et les conformer au formats attendus. Nous nous sommes retrouvé à passer
plus de temps de travail lors que nous avons envoyé tout le projet à ChatGPT plutôt que quand
nous l’avons fait progressivement.
En définitive, notre analyse a permis de révéler que l’IA seule, en tout cas aujourd’hui, ne
saurait remplacer totalement un développeur même moyen. Par contre l’utilité de l’IA est un
gain énorme de productivité. Un utilisateur sachant s’en servir un minimum, pourrait donc dans
ses tâches de développement, faire usage de cette technologie pour écrire des bouts de codes
indépendants comme des fonctions ou des classes mais devrais décrire avec précision toutes les
contraintes.
Notre point de vue sur le sujet est que les LLMs ont bien évolués jusqu’aujourd’hui et ils
continueront leur ascension. Notre prédiction est que sur le long terme les LLMs pourront ré-
pondre à beaucoup plus de problèmes de plus en plus complexes et de grande envergure. En se
basant sur ça, nous pensons que les LLMs prendront de plus en plus de place pour les projets
de programmation et on verra un remplacement progressifs des codeurs de niveau bas et moyen.
Il y aura un grand filtre progressif qui ne laissera que les développeurs les plus chevronnés avec
des parts du gâteau.
6.1 Notes :
De plus nous n’auront pas pu terminer cette discussion sans parler du prompt engineering
qui est une discipline très importante pour un travail assisté par IA. Lors de notre travail, nous
avons du communiquer aux LLMs les requêtes sous formes de textes appelés prompts. Dû à
l’architecture et à la logique de création de ces LLMs, il découle une égalité de valeur entre deux
prompts qui, dans la langue courante (Anglais ici) sont équivalents. Deux phrases équivalentes
en anglais n’ayant pas forcément la même valeur, il serait judicieux de savoir comment rédiger
de bon prompts. La sous-discipline de l’informatique qui s’occupe de cette partie s’appelle le
prompt engineering. Le prompt engineering est donc la partie de l’informatique qui a pour
objectif de créer les prompts qui donnent les meilleurs résultats pour une requête fait à un LLM.
Il serait intéressant et justifier pour un étudiant de s’atteler à se former sur le sujet.
4
7 Annexes
7.1 Quelques prompts
# Prompt initial :
"""
Hi , attached to this message is a PDF containing an assignment I need to
complete entirely with AI for a school project . Analyze it and tell
me the different phases for its complete implementation .
"""
# Prompt n 2
"""
Let ’s go for phase 1 , make me a list of features to implement .
"""
# Prompt n 3
"""
Go ahead and implement them while complying with all the constraints
listed in the document .
"""
7.2 Coordonées de contenu pour se former
Liste de livres :
Prompt Engineering for Generative AI, James Phoenix, 2024
Prompt Engineering for LLM, Albert Ziegler, 2024
Le petit livre de ChatGPT, Comment rédiger des prompts efficaces
