République Tunisienne Ministère de l’Enseignement

Supérieur et de la Recherche Scientifique

Université de la Manouba

École Nationale des Sciences de l’Informatique

Rapport de stage d’été

SECTIK

Réalisé par :

KHANTOUCHE Hasna

Encadré par :

M. Sofiene Hamza

Organisme :

DefensyLab

Année Universitaire : 2024-2025

Appréciation et signature de l’enca-
drant

Sofiene Hamza

1
Résumé — Le but de ce projet est de concevoir une extension pour Visual Studio Code,
appelée SECTIK, qui exploite les avancées récentes en intelligence artificielle et en sécurité
applicative afin d’auditer et d’améliorer la sécurité du code source. L’extension permet
de détecter dynamiquement les fichiers, de les analyser en utilisant l’API d’OpenAI,
et de vérifier leur conformité avec les normes de sécurité de l’OWASP. SECTIK inclut
également un tableau de bord dédié à l’affichage et au suivi des vulnérabilités détectées,
offrant aux utilisateurs une vue détaillée des problèmes de sécurité à résoudre. De plus,
SECTIK calcule et suit l’utilisation des jetons pour optimiser les coûts liés à l’utilisation
de l’API.

Mots Clés : Sécurité applicative, Extension VS Code, OWASP, API OpenAI, Calcul
des jetons, Audit de code, Intelligence artificielle.

2
Remerciements

”AI will change the world. It’s up to us to make sure it’s for the better—by
embedding security into every line of code, every API, every extension. ”
–Andrew Ng

Avant d’entamer la présentation de mon travail, je tiens à exprimer ma sincère gratitude

envers toutes les personnes qui m’ont soutenue tout au long de ce projet.

Je remercie particulièrement M. Sofiene Hamza, mon encadrant de stage, pour ses

conseils avisés et son accompagnement tout au long de ce projet. Ses orientations ont été
précieuses pour le bon déroulement du travail, et ses retours m’ont permis de progresser
efficacement.

Je tiens également à exprimer ma gratitude envers les membres du jury pour l’honneur
qu’ils me font en acceptant d’évaluer ce travail.

3
Table des matières

Liste des abréviations 7

Introduction 8

1 Etude préalable 10
I Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
I.1 Contexte général . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
I.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
II Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
II.1 Etude des solutions existantes . . . . . . . . . . . . . . . . . . . . 10
II.1.1 Présentation des solutions existantes . . . . . . . . . . . 11
II.1.2 Critique des solutions existantes . . . . . . . . . . . . . . 11
II.2 Solution proposée et travail demandé . . . . . . . . . . . . . . . . 12
III Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Analyse et spécification des besoins 15

I Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.1 Définition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 15
I.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . 16
II Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.1 Diagramme de cas d’utilisation relatif à l’utilisateur . . . . . . . . 17
II.2 Description de quelques scénario . . . . . . . . . . . . . . . . . . . 18
II.2.1 Scénario de Détection et Envoi des Fichiers pour Analyse 18
II.2.2 Scénario de Consultation des Résultats et Marquage des
Vulnérabilités comme Résolues . . . . . . . . . . . . . . 18
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Conception 19
I Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
I.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . 19
I.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . 20
II Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
II.1 La partie Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4
TABLE DES MATIÈRES

II.2 La partie Contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . 21

II.2.1 Scénario 1 : Détection et Envoi des Fichiers pour Analyse 22
II.2.2 Scénario 2 : Consultation des Résultats et Marquage des
Vulnérabilités comme Résolues . . . . . . . . . . . . . . 22
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Réalisation 24
I Environnements de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 24
I.1 Environnements de développement matériel . . . . . . . . . . . . 24
I.2 Environnements de développement logiciel . . . . . . . . . . . . . 24
II Implémentation et Développement . . . . . . . . . . . . . . . . . . . . . . 26
II.1 Développement de l’extension VS Code . . . . . . . . . . . . . . . 26
II.2 Développement de l’application web . . . . . . . . . . . . . . . . . 27
II.3 Architecture de communication . . . . . . . . . . . . . . . . . . . 28
III Résultats du Projet et Visualisations . . . . . . . . . . . . . . . . . . . . 29
IV Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Conclusion générale et perspectives 33

Bibliographie 34

Netographie 35

5
Table des figures

2.1 Cas d’utilisation relatif à l’utilisateur . . . . . . . . . . . . . . . . . . . . 17

3.1 Architecture Globale de l’Application SECTIK. . . . . . . . . . . . . . . 20

3.2 Diagramme de classes du projet SECTIK. . . . . . . . . . . . . . . . . . 21
3.3 Diagramme de séquences de détection et envoi des fichiers pour analyse. . 22
3.4 Diagramme de séquences de Consultation des Résultats et Marquage des
Vulnérabilités comme Résolues. . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 L’extension SECTIK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Tableau de bord des vulnérabilités. . . . . . . . . . . . . . . . . . . . . . 30
4.3 Sélection multiple de vulnérabilités. . . . . . . . . . . . . . . . . . . . . . 31
4.4 Marquage des vulnérabilités comme ”Résolues”. . . . . . . . . . . . . . . 31
4.5 Diagramme de Gantt réel. . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6
Liste des abréviations

UML Unified Modeling Language. 14, 17, 23

7
 Introduction générale

L ’évolution rapide des technologies web et la complexité croissante des systèmes logi-
ciels ont accentué les défis en matière de sécurité du code. Dans ce contexte, ga-
rantir la conformité aux meilleures pratiques de sécurité devient crucial pour prévenir les
vulnérabilités et les failles dans les applications. Le projet SECTIK vise à répondre à cette
problématique en développant non seulement une extension pour la révision de code dans
Visual Studio Code, mais aussi une interface frontend pour la gestion des vulnérabilités
détectées. Cette interface, sous forme d’un tableau de bord, permet de suivre en temps
réel les vulnérabilités et les corrections appliquées par les utilisateurs, tout en intégrant
les services d’intelligence artificielle de l’API OpenAI et les checklists de sécurité OWASP.

Ce rapport est structuré en quatre chapitres principaux qui retracent les étapes clés
du projet SECTIK :

Le premier chapitre introduit le cadre général du projet, les défis liés à la sécurité
du code, et les solutions existantes. J’y présente SECTIK, qui se distingue par une ap-
proche intégrée associant révision de code, interface utilisateur web, et optimisation des
ressources à travers l’utilisation de l’API OpenAI.

Le deuxième chapitre se concentre sur l’analyse des besoins fonctionnels et non fonc-
tionnels. Cette analyse couvre non seulement les exigences de l’extension Visual Studio
Code, mais également celles du développement de l’interface web permettant une visua-
lisation claire et interactive des vulnérabilités détectées.

Le troisième chapitre explore la conception technique et l’architecture du projet, aussi

bien pour l’extension que pour le tableau de bord. J’y discute de l’intégration entre ces
deux composants, ainsi que de la manière dont l’API OpenAI est utilisée pour évaluer le
code, et comment les résultats sont ensuite présentés à travers une interface web intuitive.

Le quatrième chapitre est dédié aux résultats obtenus, en mettant en avant comment
SECTIK aide les développeurs à identifier et corriger les failles de sécurité à travers
une plateforme unifiée, combinant une extension et une interface web réactive. J’aborde
également les aspects d’optimisation des coûts en suivant l’utilisation des jetons liés à
l’API.

Enfin, je conclus avec une récapitulation des réalisations du projet SECTIK, en met-
tant en lumière les défis techniques surmontés et les compétences acquises. J’aborde

8
Liste des abréviations

également comment cette expérience a renforcé mes connaissances en cybersécurité et en

développement logiciel, tout en ouvrant des perspectives d’amélioration pour répondre
aux enjeux futurs de la sécurité informatique.

9
Chapitre 1

Etude préalable

I Cadre général du projet

I.1 Contexte général
Avec l’augmentation des menaces de sécurité dans le développement logiciel, garantir
la conformité du code aux meilleures pratiques de sécurité est devenu une priorité es-
sentielle pour les entreprises. Les développeurs et les équipes de sécurité doivent utiliser
divers outils pour détecter les vulnérabilités et prévenir les failles de sécurité dans leurs
applications. Les solutions actuelles, telles que les outils d’analyse statique et les revues
de code manuelles, sont souvent limitées par leur capacité à suivre les normes de sécurité
en constante évolution.

I.2 Problématique
La révision de code pour la sécurité est une tâche complexe et souvent chronophage pour
les développeurs et les équipes de sécurité. Les outils de révision de code traditionnels
peuvent ne pas toujours offrir une couverture complète des normes de sécurité ou s’adapter
rapidement aux nouvelles menaces et vulnérabilités. De plus, l’intégration des checklists
de sécurité d’OWASP dans le processus de révision peut être laborieuse et nécessite
souvent une expertise spécialisée. Le manque d’automatisation dans cette analyse peut
entraı̂ner des lacunes dans la détection des failles de sécurité. Pour surmonter ces défis,
SECTIK propose une solution innovante qui automatise l’évaluation du code en utilisant
l’API OpenAI, facilitant ainsi la conformité avec les standards de sécurité tout en offrant
des recommandations adaptées pour améliorer la sécurité du code.

II Etude de l’existant
Cette section examine les solutions déjà présentes sur le marché qui répondent à des
besoins similaires.

II.1 Etude des solutions existantes

Nous analyserons ici différentes solutions existantes, en tenant compte de leurs fonc-
tionnalités et de leurs limites.

10
CHAPITRE 1. ETUDE PRÉALABLE

II.1.1 Présentation des solutions existantes

Snyk [https://snyk.io/] :
• Snyk se concentre sur la sécurité des dépendances et des conteneurs, en détectant
les vulnérabilités dans les bibliothèques tierces utilisées par les projets.
• Il offre des intégrations avec les outils CI/CD pour une détection continue des
vulnérabilités.

SonarQube [https://www.sonarqube.org/] :
• SonarQube fournit des analyses de qualité de code, y compris la détection de vulnérabilités
et de failles de sécurité en se basant sur des règles prédéfinies.
• Il supporte de nombreux langages de programmation et offre une intégration avec
divers outils de développement pour une analyse continue.

Checkmarx [https://www.checkmarx.com/] :
• Checkmarx propose une solution de scan de code source pour détecter les vulnérabilités
de sécurité avant la mise en production.
• Il utilise des techniques d’analyse statique pour identifier les failles de sécurité à
différents niveaux du code.

CodeQL [https://codeql.github.com/] :
• CodeQL permet d’effectuer des requêtes de sécurité sur le code source pour identifier
des patterns de vulnérabilités.
• Il est intégré avec GitHub pour offrir des analyses de sécurité sur les projets open
source et privés.

II.1.2 Critique des solutions existantes

Snyk :
• Concentrait principalement sur les dépendances : Snyk est principalement axé sur
les vulnérabilités des dépendances et ne couvre pas toujours les vulnérabilités dans
le code source proprement dit.
• Coût des fonctionnalités avancées : Certaines fonctionnalités avancées requièrent un
abonnement payant, ce qui peut limiter l’accès à certaines capacités.

SonarQube :
• Couverture limitée des checklists de sécurité : SonarQube se concentre sur des règles
de qualité de code généralistes et peut ne pas toujours couvrir spécifiquement les
checklists de sécurité telles que celles proposées par OWASP.
• Nécessité de configurations personnalisées : Pour obtenir une couverture complète,
une configuration et une personnalisation peuvent être nécessaires, ce qui peut com-
plexifier son utilisation.

Checkmarx :

11
CHAPITRE 1. ETUDE PRÉALABLE

• Temps de scan : Les scans peuvent être longs, surtout sur des projets de grande
envergure, ce qui peut ralentir le cycle de développement.
• Coût élevé : Checkmarx peut être coûteux, particulièrement pour les petites entre-
prises ou les projets à budget limité.

CodeQL :
• Courbe d’apprentissage : CodeQL nécessite une compréhension approfondie de son
langage de requêtes pour écrire des requêtes efficaces.
• Dépendance à GitHub : CodeQL est fortement intégré à GitHub, ce qui peut res-
treindre son utilisation dans des environnements de développement non-GitHub.

II.2 Solution proposée et travail demandé

Après avoir examiné les solutions existantes, nous avons identifié le besoin d’une ap-
proche plus intégrée et automatisée pour la révision de code axée sur la sécurité. La
solution proposée, SECTIK, répond à cette exigence en utilisant l’API OpenAI pour
analyser le code en fonction des checklists de sécurité d’OWASP tout en fournissant un
tableau de bord interactif pour la gestion des vulnérabilités.

Notre solution vise à améliorer la sécurité du code grâce aux fonctionnalités suivantes :

1. Analyse automatisée des checklists de sécurité : SECTIK utilise l’API OpenAI

pour vérifier automatiquement le code contre les checklists de sécurité d’OWASP,
fournissant des évaluations et des recommandations basées sur les meilleures pra-
tiques en matière de sécurité.

2. Intégration dans les environnements de développement : SECTIK s’intègre

directement dans les outils de développement comme VS Code pour une révision de
code fluide et intégrée, réduisant le besoin de passer par des processus de révision
séparés.

3. Recommandations contextuelles :L’extension offre des recommandations per-

sonnalisées et contextuelles pour améliorer la sécurité du code, en se basant sur des
analyses avancées réalisées par l’API OpenAI.

4. Tableau de bord des vulnérabilités : En plus de l’extension, SECTIK propose

une interface web qui affiche un tableau de bord permettant aux développeurs de
visualiser les vulnérabilités détectées, de suivre les corrections, et de marquer les
failles comme résolues.

12
CHAPITRE 1. ETUDE PRÉALABLE

III Méthodologie adoptée

Le succès du projet SECTIK repose sur l’adoption d’une méthodologie rigoureuse
pour assurer une intégration fluide de l’API OpenAI, l’application efficace des checklists
de sécurité OWASP, et la mise en place d’un tableau de bord interactif pour le suivi des
vulnérabilités. La méthodologie adoptée pour ce projet est structurée en plusieurs étapes
clés :
— Définition des besoins et planification : Identification des exigences spécifiques
du projet SECTIK, y compris les fonctionnalités de l’extension pour la révision de
code, l’intégration avec l’API OpenAI, et l’application des checklists OWASP. Ajout
du tableau de bord dans la web app pour l’affichage des vulnérabilités détectées
et leur statut (résolu ou non résolu). Élaboration d’un plan de projet détaillé in-
cluant les objectifs, les ressources nécessaires, et les interactions entre les différents
composants.
— Analyse et conception : Analyse des exigences fonctionnelles et non fonctionnelles
pour SECTIK. Conception de l’architecture de l’extension, y compris les interactions
entre l’extension VS Code, l’API OpenAI, et les checklists OWASP. Conception du
tableau de bord React pour le suivi des vulnérabilités. Élaboration de diagrammes
UML pour modéliser les composants du système et leurs interactions, notamment
les flux entre l’extension, la web app et le back-end.
— Développement et intégration : Développement de l’extension SECTIK en uti-
lisant les meilleures pratiques de programmation. Intégration de l’API OpenAI pour
la révision du code et application des checklists OWASP pour évaluer la sécurité du
code. Développement de la web app pour visualiser et gérer les vulnérabilités. Mise
en place d’un environnement de test pour assurer la compatibilité et la performance
de l’extension.
— Test et validation : Réalisation de tests fonctionnels et de validation pour vérifier
que l’extension et la web app répondent aux exigences spécifiées. Tests de perfor-
mance pour garantir que l’intégration de l’API OpenAI fonctionne correctement et
que les checklists OWASP sont appliquées efficacement. Validation du bon fonction-
nement du tableau de bord pour la gestion des vulnérabilités et de la communication
entre les différents composants du projet.
— Déploiement et mise en production : Préparation de la mise en production de
SECTIK, y compris l’extension et la web app. Déploiement dans l’environnement
de développement (VS Code pour l’extension et la web app). Mise en place de
mécanismes de suivi pour surveiller les performances, l’usage des tokens OpenAI, et
la résolution des vulnérabilités via le tableau de bord.

Cette méthodologie permet une approche systématique et structurée pour le développement

de SECTIK, garantissant une intégration réussie de l’API OpenAI et une application effi-
cace des standards de sécurité. En suivant ces étapes, nous assurons que le projet répond
aux exigences des utilisateurs tout en respectant les meilleures pratiques en matière de
développement logiciel et de sécurité.

13
CHAPITRE 1. ETUDE PRÉALABLE

Conclusion
Ce chapitre présente la méthodologie adoptée pour le projet SECTIK, en mettant
en évidence les différentes étapes nécessaires pour le développement et l’intégration de
l’extension.

Le chapitre suivant se concentrera sur les besoins fonctionnels et non fonctionnels

du projet SECTIK. Nous y fournirons une spécification détaillée, soutenue par des dia-
grammes d’Unified Modeling Language (UML), pour illustrer les exigences et les interac-
tions du système.

14
 Chapitre 2

Analyse et spécification des besoins

L ’application SECTIK que nous développons doit répondre aux exigences des différents
utilisateurs impliqués dans le processus de révision de code et de sécurité. Pour ce
faire, il est essentiel de réaliser une analyse approfondie des besoins des acteurs concernés.
Le chapitre actuel se divise en deux parties principales : d’abord, nous présentons les
besoins fonctionnels et non fonctionnels des différents acteurs. Ensuite, nous spécifions
ces besoins à l’aide de diagrammes de cas d’utilisation.

I Capture des besoins

L’analyse des besoins est cruciale pour garantir le succès de l’application SECTIK.
Il est donc impératif de déterminer avec précision les fonctionnalités attendues et les
contraintes auxquelles le système doit répondre.

I.1 Définition des acteurs

Nous avons identifié un acteur principal pour le projet SECTIK : l’utilisateur.
• Utilisateur : Que ce soit un développeur ou un responsable de la sécurité informa-
tique, l’utilisateur bénéficie d’un audit de code automatisé et de recommandations
fournies par l’API OpenAI, ce qui l’aide à améliorer la qualité et la sécurité du code.
Le tableau de bord intégré permet de suivre les vulnérabilités détectées et de gérer
leur résolution de manière efficace. L’utilisateur peut ainsi s’assurer que les standards
de sécurité définis par les checklists OWASP sont respectés, renforçant la sécurité
globale des systèmes informatiques.

I.2 Analyse des besoins

Les besoins sont généralement classés en deux catégories : les besoins fonctionnels,
qui décrivent les actions spécifiques que le système doit effectuer, et les besoins non
fonctionnels, qui définissent les contraintes et les exigences de qualité que le système doit
respecter.

I.2.1 Besoins fonctionnels

Les besoins fonctionnels concernent les actions et les réponses que l’application SECTIK
doit fournir en réponse aux demandes des utilisateurs principaux.

15
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS

Fonctionnalités de l’Extension :
• Sélection de Fichiers : L’extension doit permettre à l’utilisateur de sélectionner des
fichiers pour l’analyse.
• Suivi des Tokens : Suivre et gérer l’utilisation des tokens pour optimiser les coûts.

Fonctionnalités de la Web App :

• Audit Automatisé : La Web App doit être capable de réaliser un audit de code
automatisé en utilisant l’API OpenAI pour détecter les vulnérabilités potentielles et
les problèmes de qualité.
• Application des Checklists OWASP : La Web App doit intégrer les checklists OWASP
pour évaluer la conformité du code aux meilleures pratiques de sécurité.
• Affichage des Vulnérabilités : La web app doit permettre l’affichage des vulnérabilités
détectées, avec des détails sur chaque problème.
• Gestion des Statuts : Les utilisateurs doivent pouvoir marquer les vulnérabilités
comme ”résolues” une fois qu’elles ont été corrigées. Le tableau de bord doit refléter
en temps réel les changements de statut.

Intégration et Communication :
• Communication avec le Serveur : L’extension doit être capable de communiquer avec
le serveur pour l’envoi des demandes d’analyse et la réception des résultats.
• Intégration des Composants : Assurer une intégration fluide entre l’extension VS
Code, l’API OpenAI, et la web app.

I.2.2 Besoins non fonctionnels

Les besoins non fonctionnels concernent la manière dont l’application SECTIK est uti-
lisée et les conditions dans lesquelles elle doit opérer.

Performance et Réactivité
• Temps de Réponse : L’extension doit fournir des résultats d’audit rapidement pour
ne pas impacter la productivité de l’utilisateur.
• Scalabilité : Le système doit être capable de gérer un volume croissant de code et de
vulnérabilités sans dégradation significative des performances.

Sécurité
• Protection des Données : Les données sensibles et les résultats d’audit doivent être
protégés contre les accès non autorisés.
• Conformité aux Normes : L’extension et la web app doivent respecter les normes de
sécurité en vigueur, notamment en ce qui concerne la protection des informations
des utilisateurs.

Facilité d’utilisation

16
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS

• L’application doit offrir une interface simple et intuitive pour permettre aux utilisa-
teurs de tirer parti des fonctionnalités

II Spécification des besoins

Pour spécifier les besoins, nous utiliserons les diagrammes d’UML, notamment les dia-
grammes de cas d’utilisation et les diagrammes de séquence.

II.1 Diagramme de cas d’utilisation relatif à l’utilisateur

Le diagramme qui illustre les cas d’utilisation spécifiques à l’utilisateur de l’application
est représenté par la figure 2.1 ci-dessous.

Figure 2.1 – Cas d’utilisation relatif à l’utilisateur

Le diagramme de cas d’utilisation détaille les interactions entre l’utilisateur et l’ex-

tension SECTIK dans VS Code. Il montre comment l’utilisateur peut sélectionner des
fichiers pour l’analyse, lancer un audit de code, recevoir des alertes sur les vulnérabilités
détectées, consulter les détails de ces vulnérabilités, et corriger le code en conséquence.
Une fois les corrections apportées, l’utilisateur peut marquer les vulnérabilités comme
résolues et suivre l’utilisation des tokens pour optimiser les coûts. Ce diagramme illustre
les actions principales que l’utilisateur peut effectuer pour garantir la qualité et la sécurité
du code.

17
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS

II.2 Description de quelques scénario

II.2.1 Scénario de Détection et Envoi des Fichiers pour Analyse
L’utilisateur commence par sélectionner les fichiers qu’il souhaite analyser dans l’ex-
tension VS Code. L’extension détecte ces fichiers et les divise en morceaux plus petits à
l’aide de Tree-sitter, un outil de parsing. Ces morceaux de fichiers sont ensuite envoyés à
l’application web, qui reçoit également les instructions nécessaires pour l’analyse. L’appli-
cation web transmet les fichiers divisés à l’API OpenAI pour l’analyse des vulnérabilités.
Après avoir traité les fichiers, l’API OpenAI renvoie les résultats d’analyse à l’application
web. Cette dernière parse les résultats reçus et les transmet à l’extension VS Code. Enfin,
l’extension affiche les résultats d’analyse à l’utilisateur, permettant ainsi de visualiser les
vulnérabilités détectées et d’interagir avec elles.

II.2.2 Scénario de Consultation des Résultats et Marquage des Vulnérabilités

comme Résolues
Dans ce scénario, l’utilisateur se connecte à l’application web pour consulter les résultats
des analyses de vulnérabilités. Une fois connecté, l’application web demande les résultats
d’analyse à la base de données. Celle-ci renvoie les informations demandées, que l’appli-
cation web affiche ensuite à l’utilisateur. Après avoir examiné les résultats, l’utilisateur
sélectionne certaines vulnérabilités et choisit de les marquer comme résolues. L’applica-
tion web envoie cette demande de mise à jour à la base de données, qui ajuste le statut
des vulnérabilités concernées et confirme les modifications. En réponse, l’application web
met à jour l’affichage pour refléter les vulnérabilités désormais marquées comme résolues
et informe l’utilisateur des changements apportés.

Conclusion
Le chapitre ”Analyse et Spécification des Besoins” a clarifié les exigences essentielles
du projet SECTIK, en détaillant les fonctionnalités nécessaires pour l’audit de code,
la gestion des vulnérabilités, et l’intégration des outils. Dans le prochain chapitre, on
débutera la section de conception.

18
 Chapitre 3

Conception

C e détaillée
chapitre se penchera sur l’élément crucial du développement, à savoir la définition
de l’architecture et des composants du système. Nous commencerons par
une vue d’ensemble de l’architecture intégrée, englobant l’extension VS Code, la web app,
et l’API OpenAI. Ensuite, nous explorerons en détail chaque composant, en utilisant des
notations UML pour décrire les diagrammes de classes et de séquences. Cette approche
nous permettra de visualiser et de spécifier les interactions entre les différentes parties du
projet et d’assurer une conception cohérente et fonctionnelle.

I Conception globale
I.1 Architecture physique
L’architecture quatre tiers a été choisie pour la conception de cette application. Elle
vise à différencier quatre niveaux logiciels au sein d’une application, en les présentant
comme un empilement de couches distinctes dont le rôle est bien défini :

Couche de Présentation
Ce niveau comprend l’extension VS Code et la web app. Il est responsable de l’interface
utilisateur, permettant aux utilisateurs d’interagir avec l’application, de sélectionner des
fichiers, de lancer des audits de code, et de consulter les résultats.

Couche de Logique Métier

Ici se trouve le serveur backend. Cette couche gère la logique métier de l’application,
coordonne les requêtes entre la présentation et les services, et applique les règles définies
pour le traitement et l’analyse des données.

Couche de Services
Cette couche inclut l’API OpenAI, qui est utilisée pour l’analyse du code et la détection
des vulnérabilités. Elle fournit les services nécessaires pour effectuer des audits automa-
tisés et appliquer des checklists de sécurité.

Couche de Données
La base de données représente ce niveau, stockant les informations relatives aux fichiers

19
CHAPITRE 3. CONCEPTION

analysés, aux résultats des audits, et aux statistiques d’utilisation des tokens. Cette couche
assure la persistance des données et leur gestion efficace.

La figure 3.1 ci-dessous illustre l’architecture globale de l’application SECTIK, en

présentant les différentes couches et services impliqués dans le processus d’analyse et de
gestion des vulnérabilités.

Figure 3.1 – Architecture Globale de l’Application SECTIK.

I.2 Architecture logique

L’architecture microservices a été choisie pour la conception de l’application SECTIK.
Cette approche permet de structurer l’application en plusieurs services indépendants,
chacun étant responsable d’une fonctionnalité spécifique, ce qui facilite la modularité et
la gestion des différentes composantes du système.

Service d’Extension VS Code :

• Gère les interactions avec l’utilisateur au sein de l’environnement de développement,
permettant la sélection des fichiers et le lancement des audits de code.

Service de Web App :

• Fournit une interface pour visualiser et gérer les vulnérabilités détectées, et permet
aux utilisateurs de marquer les problèmes comme résolus. Ce service communique
avec les autres composants pour récupérer les données nécessaires.

Service de Serveur :
• Agit comme le cœur du système, orchestrant les interactions entre les différents
services. Il gère les demandes des utilisateurs, interagit avec l’API OpenAI pour
l’analyse de code, et communique avec la base de données pour stocker et récupérer
les informations.

API OpenAI :
• Intégrée comme un service externe, elle effectue l’analyse de code et détecte les
vulnérabilités. Ce service est indépendant mais fournit des résultats au service de

20
CHAPITRE 3. CONCEPTION

traitement.

Service de Base de Données :

• Stocke les informations relatives aux fichiers, aux vulnérabilités détectées, et à l’uti-
lisation des tokens. Ce service est séparé des autres composants pour permettre une
gestion efficace et une récupération optimale des données.

II Conception détaillée
Dans cette section, nous allons commencer à présenter les spécificités conceptuelles du
projet SECTIK.

II.1 La partie Modèle

La figure 3.2 ci-dessous représente le diagramme de classes qui illustre la structure sta-
tique du projet SECTIK, en mettant en évidence les principales classes et leurs relations.

Figure 3.2 – Diagramme de classes du projet SECTIK.

On y trouve SECTIKExtension, qui représente l’extension VS Code, WebApp, l’ap-

plication web qui communique avec l’API OpenAI, et OpenAIAPI, l’API responsable
de l’analyse des vulnérabilités. La classe AnalysisResults capture les résultats d’analyse
retournés par l’API OpenAI.

II.2 La partie Contrôle

Dans cette section, nous allons explorer des scénarios de diagrammes de séquence pour
illustrer les interactions entre les différents composants du projet SECTIK. Voici quelques

21
CHAPITRE 3. CONCEPTION

scénarios clés pour votre système :

II.2.1 Scénario 1 : Détection et Envoi des Fichiers pour Analyse

La figure 3.3 ci-dessous représente le scénario qui illustre comment l’extension VS Code
détecte les fichiers, les envoie à la web app, qui à son tour les transmet à l’API OpenAI
pour l’analyse.

Figure 3.3 – Diagramme de séquences de détection et envoi des fichiers pour analyse.

L’extension VS Code commence par détecter les fichiers de code à analyser, en utili-
sant Linguist pour identifier le langage de chaque fichier et Tree-sitter pour segmenter le
code en morceaux plus petits. Une fois ces fichiers prêts, ils sont envoyés à l’application
web, qui joue un rôle central en recevant les fichiers et en les préparant pour l’analyse.
L’application web transmet ensuite ces fichiers à l’API OpenAI pour une analyse appro-
fondie. Après traitement, l’API renvoie les résultats d’analyse à l’application web, où ils
sont filtrés et présentés de manière structurée, incluant les vulnérabilités détectées, leur
statut, leur priorité, ainsi que les recommandations pour les résoudre. Enfin, ces résultats
sont renvoyés à l’extension VS Code, permettant ainsi à l’utilisateur de visualiser les
informations directement dans l’extension.

II.2.2 Scénario 2 : Consultation des Résultats et Marquage des Vulnérabilités comme

Résolues

La figure 3.4 ci-dessous représente le scénario qui illustre comment l’utilisateur consulte
les résultats d’analyse des vulnérabilités via la web app et marque certaines vulnérabilités
comme résolues.

Après que l’application web ait reçu et affiché les résultats d’analyse des vulnérabilités
détectées par l’API OpenAI, l’utilisateur peut consulter ces résultats directement via le ta-
bleau de bord de l’application web. Chaque vulnérabilité est listée avec des détails tels que

22
CHAPITRE 3. CONCEPTION

Figure 3.4 – Diagramme de séquences de Consultation des Résultats et Marquage des Vulnérabilités
comme Résolues.

le statut, la priorité, et les recommandations pour la correction. Lorsque l’utilisateur cor-

rige une vulnérabilité dans le code, il peut mettre à jour son statut en la marquant comme
résolue dans l’interface de l’application web. Ce marquage est effectué en sélectionnant une
option appropriée dans l’interface utilisateur. Une fois qu’une vulnérabilité est marquée
comme résolue, l’application web envoie cette information de mise à jour à l’extension
VS Code. Cette action entraı̂ne l’élimination de la vulnérabilité de la liste des problèmes
actifs. Ce scénario assure une synchronisation entre l’application web et l’extension VS
Code, offrant une visibilité et un suivi cohérents des vulnérabilités à travers les deux
interfaces.

Conclusion
Dans ce chapitre, nous avons présenté notre conception de l’application. Tout d’abord,
nous avons exposé une perspective globale de l’organisation de notre système. La concep-
tion de l’application a ensuite été exposée en détail à l’aide des diagrammes UML. Par
la suite, nous pouvons entamer la phase de réalisation.

23
 Chapitre 4

Réalisation

C e chapitre présente en détail les différentes étapes de la réalisation du projet SECTIK.

Nous commencerons par décrire l’environnement matériel et logiciel utilisé pour le
développement, puis nous aborderons les technologies employées, tant pour l’extension
Visual Studio Code que pour l’application web. Cette dernière comprend un tableau de
bord permettant de visualiser et de suivre les vulnérabilités détectées. Nous explorerons
les interfaces utilisateurs, ainsi que l’intégration entre l’API OpenAI et le tableau de bord,
qui permet de gérer les vulnérabilités et de suivre leur résolution. Enfin, un récapitulatif
des tâches réalisées et un chronogramme des étapes clés du projet seront proposés pour
synthétiser l’ensemble du travail accompli.

I Environnements de travail
Durant la création de ce projet, on a employé des équipements et des logiciels spécifiques.

I.1 Environnements de développement matériel

Pour mener à bien le projet SECTIK, un poste de travail a été utilisé avec les ca-
ractéristiques suivantes :

Poste de travail :
- Système d’exploitation : Windows 11
- Disque dur : 1 To
- Ram : 16 Go
- Processeur : 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz 2.42 GHz

I.2 Environnements de développement logiciel

Dans cette partie, on étudie les langages, les bibliothèques et les techniques de pro-
grammation utilisées lors de la conception.
♦ Frameworks

React :

24
CHAPITRE 4. RÉALISATION

• Utilisé pour le développement de l’application web.

• Permet de créer des interfaces utilisateur dynamiques et réactives.

• Gère l’affichage des vulnérabilités et recommandations en temps réel.

Flask :
• Framework léger en Python pour le développement du backend.

• Gère les API RESTful et la communication avec l’API OpenAI.

• Utilisé pour recevoir les requêtes de l’application web et retourner les résultats
d’analyse de code.

♦ Outils et Langages

TypeScript :
• Langage utilisé pour le développement de l’extension VS Code.

• Ajoute des fonctionnalités de typage statique à JavaScript pour améliorer la

fiabilité du code.

Svelte :
• Utilisé pour le développement de l’interface utilisateur dans l’extension VS Code.

• Compile les composants en JavaScript optimisé pour des performances élevées.

• Le composant sidebar.svelte gère l’affichage des résultats et des recommanda-

tions.

♦ Bibliothèques utilisées

Axios :
• Bibliothèque JavaScript pour effectuer des requêtes HTTP.

• Utilisée pour la communication entre le frontend et le backend, permettant

l’échange de données entre l’application web et l’API.

Tree-sitter :
• Utilisé pour le découpage et l’analyse du code source dans l’extension VS Code.

25
CHAPITRE 4. RÉALISATION

• Optimise le comptage des jetons et améliore la performance en analysant le code

de manière incrémentielle.

Linguist :
• Utilisé pour détecter les types de fichiers et sélectionner les fichiers de code à
analyser.

Tiktokenizer :
• Utilisé pour le découpage et le comptage des tokens dans le code pour optimiser
les requêtes à l’API OpenAI.

OpenAI :
• Bibliothèque pour intégrer l’API OpenAI et effectuer des analyses de code.

JSON :
• Utilisé pour la gestion et le parsing des données échangées entre les composants.

II Implémentation et Développement
II.1 Développement de l’extension VS Code
Le développement de l’extension VS Code commence par la configuration des scripts
dans extension.ts. Cette configuration inclut la définition des commandes et des inter-
actions utilisateur, permettant d’exécuter les actions de manière fluide et intuitive. La
classe SidebarProvider.ts joue un rôle central dans la gestion de la communication entre
l’extension et la webapp. Elle est responsable de l’envoi des fichiers détectés et segmentés
pour analyse, ainsi que de la réception des résultats d’analyse depuis la webapp.
L’affichage des résultats d’analyse dans l’extension se fait via sidebar.svelte, qui génère
une interface utilisateur interactive. Cette interface permet non seulement de présenter
les résultats de l’analyse de manière claire et structurée, mais offre également à l’utilisa-
teur la possibilité d’interagir directement avec les données.
Le lien entre sidebar.svelte et SidebarProvider.ts permet de créer une expérience utilisa-
teur fluide, où les résultats sont mis à jour en temps réel dans l’extension, garantissant
ainsi une interaction continue entre l’utilisateur et l’outil d’analyse.

L’extension utilise Linguist pour détecter les fichiers de code et identifier précisément
le langage de chaque fichier. Cette détection est cruciale pour garantir que chaque fichier
soit traité et analysé en fonction de ses spécificités linguistiques, assurant ainsi une ana-
lyse plus précise et pertinente. En effet, chaque langage de programmation possède des
structures syntaxiques et sémantiques uniques, et Linguist permet de classifier automa-
tiquement ces fichiers, facilitant ainsi le processus d’analyse.

Une fois les fichiers détectés et classifiés, l’utilisateur a la possibilité de sélectionner les

26
CHAPITRE 4. RÉALISATION

fichiers qu’il souhaite analyser. Cette étape est particulièrement importante dans le cas
de projets contenant un grand nombre de fichiers, car l’utilisateur peut choisir de ne sou-
mettre à l’analyse que les fichiers les plus pertinents, réduisant ainsi les coûts en termes
de jetons lors de l’interaction avec l’API d’OpenAI.

Pour optimiser l’analyse du code, Tree-sitter, un analyseur syntaxique puissant et précis,

est intégré. Tree-sitter permet de diviser le code en segments logiques basés sur la struc-
ture syntaxique du fichier. Ce découpage est essentiel, car il permet de traiter des portions
de code plus petites et plus gérables, facilitant ainsi l’analyse par l’API d’OpenAI.
Le découpage du code en morceaux présente plusieurs avantages. Premièrement, en seg-
mentant le fichier, le nombre de jetons nécessaires à chaque requête envoyée à l’API est
réduit. L’API OpenAI impose une limite stricte sur le nombre de jetons qu’elle peut
traiter dans une seule requête, ce qui inclut à la fois les tokens du texte soumis et ceux
générés en réponse. Si un fichier entier était soumis sans être découpé, il y aurait un
risque de dépasser cette limite, entraı̂nant des erreurs d’exécution ou des interruptions
dans le processus d’analyse.
Deuxièmement, le découpage permet également de réduire les coûts. Comme le modèle
OpenAI facture en fonction du nombre de jetons utilisés, une soumission massive et non
optimisée d’un fichier pourrait entraı̂ner des dépenses inutiles. En soumettant unique-
ment des segments pertinents et bien structurés, le processus d’analyse est optimisé et
les coûts liés à l’utilisation de l’API sont réduits. Cela garantit une utilisation efficace de
chaque jeton, évitant les analyses superflues de grandes portions de code non pertinentes.

En termes de techniques, l’extension repose fortement sur l’API VS Code, qui offre plu-
sieurs fonctionnalités indispensables pour la gestion des fichiers et des interactions utili-
sateur. Grâce à cette API, il est possible d’implémenter des commandes personnalisées,
de gérer dynamiquement les événements de l’éditeur, et d’interagir avec l’arborescence
des fichiers. Par exemple, l’API permet d’écouter les modifications de fichiers, d’afficher
des résultats dans des panneaux personnalisés, et de créer des interfaces interactives à
travers les webviews. L’intégration avec l’API assure également une expérience utilisateur
fluide et une flexibilité accrue dans l’analyse en temps réel du code.

II.2 Développement de l’application web

L’application web, développée en React, joue un rôle central en tant que tableau de
bord pour la visualisation et la gestion des vulnérabilités détectées. Le tableau de bord
présente de manière organisée les détails des vulnérabilités identifiées lors des analyses,
incluant des informations telles que le statut, la priorité, la gravité et des recommanda-
tions pour chaque vulnérabilité.

Chaque vulnérabilité détectée peut être marquée comme résolue une fois corrigée dans le
code. Les utilisateurs ont la possibilité de cocher une vulnérabilité comme résolue direc-
tement depuis le tableau de bord. Cette action met automatiquement à jour le statut de
la vulnérabilité, ce qui est ensuite communiqué au backend et envoyé à l’extension VS
Code pour synchronisation. Cette interaction permet à l’extension de mettre à jour l’état
des fichiers analysés et de confirmer que les correctifs ont été appliqués.

27
CHAPITRE 4. RÉALISATION

L’application web ne se limite pas à la réception des résultats d’analyse, elle joue également
un rôle actif en renvoyant des informations à l’extension. Lorsqu’une vulnérabilité est
marquée comme résolue sur l’application web, cette mise à jour est renvoyée à l’extension
VS Code, assurant ainsi une synchronisation bidirectionnelle. Cela permet aux utilisa-
teurs de gérer les vulnérabilités de manière centralisée depuis l’interface web, tout en
ayant une vue à jour dans l’extension.

Axios est utilisé pour la communication entre l’application web et le serveur backend.
Les résultats d’analyse sont reçus du backend, traités, et affichés sur le tableau de bord.
Les recommandations générées par OpenAI sont également intégrées dans l’interface uti-
lisateur pour offrir des conseils contextuels sur la manière de corriger les vulnérabilités.
Grâce à ces recommandations, les développeurs peuvent comprendre non seulement la na-
ture des vulnérabilités détectées, mais aussi les étapes concrètes à suivre pour y remédier
efficacement.

II.3 Architecture de communication

L’architecture de communication repose sur une interaction bien orchestrée entre trois
éléments clés : l’extension VS Code, l’application web et le serveur backend, avec l’API
OpenAI jouant un rôle essentiel dans l’analyse des fichiers.

Lorsque l’utilisateur sélectionne des fichiers à analyser depuis l’extension VS Code, ceux-
ci sont envoyés directement à l’application web, et non au backend, pour des raisons de
sécurité. En centralisant cette interaction via l’application web, les informations sensibles
ne sont pas exposées directement au backend, réduisant ainsi le risque de compromission.
Cette approche permet de limiter les points d’entrée potentiels pour des attaques.
Une fois que l’application web reçoit les fichiers, elle les traite en interne et se charge de
les transmettre au serveur backend, qui envoie ensuite les fichiers à l’API OpenAI pour
analyse. Cette double étape assure que le backend n’a pas directement accès aux fichiers
envoyés par l’utilisateur, ce qui renforce la sécurité du système.

Après l’analyse par l’API OpenAI, les résultats sont filtrés par le backend et envoyés
à l’application web, qui affiche les vulnérabilités, leur statut, leur priorité, et les recom-
mandations d’OpenAI. L’application web permet également de marquer une vulnérabilité
comme résolue une fois corrigée, et met à jour ce statut dans l’extension VS Code pour
une visualisation en temps réel.
Ce flux de communication bidirectionnel garantit que l’extension VS Code et l’applica-
tion web sont synchronisées en temps réel, offrant une expérience utilisateur cohérente.
Tandis que l’extension se concentre sur l’affichage local des résultats d’analyse et des
recommandations dans l’environnement de développement, l’application web fournit une
vue d’ensemble globale avec un suivi des vulnérabilités.

Cette séparation des rôles et des flux de données est essentielle pour assurer la sécurité du
système tout en facilitant une interaction fluide entre les différents composants. Le choix
de faire transiter les fichiers par l’application web, plutôt que de les envoyer directement

28
CHAPITRE 4. RÉALISATION

au backend, limite les risques de sécurité liés à la gestion des fichiers sensibles.

III Résultats du Projet et Visualisations

Cette partie met en lumière les performances et les fonctionnalités de la solution à
travers une série de visualisations, permettant ainsi d’illustrer concrètement les succès et
les défis rencontrés. Les captures d’écran et graphiques fournis démontrent l’efficacité de
l’extension VS Code, de l’application web, et du backend dans l’audit de code et la gestion
des vulnérabilités. Nous explorerons également les insights obtenus à partir des analyses
réalisées, mettant en avant les principales recommandations et améliorations possibles.

La figure 4.1 ci-dessous représente l’interface de l’extension SECTIK intégrée à Visual

Studio Code.

Figure 4.1 – L’extension SECTIK.

Dans le volet de gauche, l’utilisateur peut sélectionner des fichiers à analyser (comme
main.js, auth.js, admin.js, et readme.md) en cochant les cases correspondantes. L’exten-
sion offre également un aperçu de l’état des vérifications de sécurité via l’API OWASP,
avec des indicateurs de succès ou d’échec (ici, 12 vérifications réussies et 10 échouées).
Parmi les vulnérabilités détectées, on peut observer la mention de failles critiques comme
l’authentification défaillante (Broken authentication) et la consommation de ressources
non restreinte (Unrestricted resource consumption), indiquées par des icônes rouges si-
gnalant une priorité élevée.

Enfin, la section ”Tokens” située en bas de l’interface permet de suivre l’utilisation des
jetons, une fonctionnalité essentielle pour contrôler les coûts liés à l’utilisation des APIs

29
CHAPITRE 4. RÉALISATION

comme celle d’OpenAI. Ici, on voit qu’un total de 1000 jetons est disponible, avec 500
déjà utilisés et 500 restants.

La figure 4.2 ci-dessous représente l’interface utilisateur de l’application web qui suit
les vulnérabilités et leur statut.

Figure 4.2 – Tableau de bord des vulnérabilités.

Ce tableau de bord offre un aperçu clair et détaillé de l’état de sécurité d’un projet,
en mettant en avant les vulnérabilités critiques, élevées, moyennes et faibles. Voici les
éléments clés :
• Le graphique circulaire en haut à gauche indique le nombre total de vulnérabilités
détectées, ici 7, réparties par niveau de gravité : 2 critiques, 3 élevées, 1 moyenne,
et 1 faible.

• Juste à côté, des indicateurs colorés permettent d’identifier rapidement les catégories
de vulnérabilités par leur gravité, de la plus critique à la moins dangereuse.

• La partie centrale liste les vulnérabilités spécifiques. On peut voir deux vulnérabilités
détectées : Brute Force Attack et Unrestricted File Upload

• Une fonctionnalité de filtre permet de trier les vulnérabilités par statut : Résolu,
Ouvert, ou Accepté. Ici, les deux vulnérabilités sont marquées comme ouvertes.

• Une option d’exportation est disponible, pour générer des rapports détaillés.

30
CHAPITRE 4. RÉALISATION

Cette interface met clairement en lumière les vulnérabilités critiques et offre des recom-
mandations pratiques pour chaque problème détecté.

La figure 4-3 ci-dessous illustre la possibilité de sélectionner une ou plusieurs vulnérabilités.

Figure 4.3 – Sélection multiple de vulnérabilités.

Les cases à cocher situées à gauche de chaque ligne permettent à l’utilisateur de choisir
les vulnérabilités qu’il souhaite gérer en groupe. Cette fonctionnalité améliore l’efficacité
en permettant de sélectionner plusieurs éléments pour effectuer des actions en masse,
comme les modifications ou les résolutions.

La figure 4-4 présente l’option de marquer les vulnérabilités sélectionnées comme

”Résolues”.

Figure 4.4 – Marquage des vulnérabilités comme ”Résolues”.

Une fois les vulnérabilités choisies, l’utilisateur peut décider de leur attribuer un nou-
veau statut, facilitant ainsi la gestion des risques. Cette fonctionnalité assure une bonne

31
CHAPITRE 4. RÉALISATION

traçabilité et permet de suivre l’avancement des correctifs appliqués.

IV Chronogramme
Ce projet a été effectuée sur une durée de 2 mois. Le diagramme de Gantt réel de la
figure 4.3 ci-dessous illustre la répartition des tâches tout au long de la réalisation du
projet.

Figure 4.5 – Diagramme de Gantt réel.

Conclusion
L’ensemble du travail effectué lors de ce projet de conception et de développement
est résumé dans ce chapitre, ainsi que les résultats obtenus. En effet, on a présenté les
infrastructures matérielles et logicielles sur lesquelles on a l’application. Par la suite, on
a présenté quelques interfaces de l’application, puis on a conclu ce chapitre en exposant
le calendrier des tâches.

32
Conclusion générale et perspectives

C e spécialisée
stage d’immersion en entreprise a été réalisé au sein de DefensyLab, une société
dans la cybersécurité et le développement de solutions avancées pour
la protection des systèmes informatiques. Il s’inscrit dans le cadre de la création et de
la mise en œuvre du projet SECTIK, une plateforme innovante dédiée à l’audit de code
automatisé et à la gestion des vulnérabilités.

Avant de débuter ce projet, je pensais que les objectifs définis seraient atteints de
manière fluide et directe. Cependant, au fur et à mesure de la progression du projet, j’ai
pris conscience des défis complexes auxquels j’étais confrontée. La création d’une exten-
sion VS Code intégrée à une application web et à un backend utilisant l’API OpenAI a
révélé des obstacles imprévus. La principale difficulté résidait dans la synchronisation des
interactions entre les différents composants du système et l’optimisation des performances
pour une utilisation en temps réel.

Le développement de SECTIK a nécessité une compréhension approfondie des techno-

logies utilisées, telles que TypeScript pour l’extension, React pour le tableau de bord, et
Flask pour le backend. La mise en place de la communication sécurisée entre l’extension,
l’application web, et l’API OpenAI a été un aspect central du projet, garantissant à la
fois la sécurité des données et l’efficacité des processus d’analyse.

Ce projet a été extrêmement enrichissant, tant sur le plan professionnel que person-
nel. Il m’a permis d’acquérir une expérience précieuse en développement logiciel, en cy-
bersécurité et en intégration de systèmes complexes. J’ai également appris à gérer des défis
techniques, à travailler de manière autonome, et à collaborer efficacement avec une équipe
d’experts. L’encadrement et le soutien reçus au sein de DefensyLab ont été déterminants
dans la réussite de ce projet.

En conclusion, ce stage a non seulement renforcé mes compétences techniques, mais

m’a également permis de mieux comprendre les enjeux de la cybersécurité moderne. Je
suis très satisfaite du travail accompli et des connaissances acquises au cours de cette
expérience, qui marque une étape importante dans mon parcours professionnel.

33
Bibliographie

1. Martin, R.C. (2008). Clean Code : A Handbook of Agile Software Craftsmanship.

Prentice Hall.
2. OWASP Foundation. (2017). OWASP Top 10 : The Ten Most Critical Web Appli-
cation Security Risks. OWASP Foundation.
3. Van Roy, P., & Haridi, S. (2004). Concepts, Techniques, and Models of Computer
Programming. MIT Press.
4. Larman, C. (2004). Agile and Iterative Development : A Manager’s Guide. Addison-
Wesley.
5. Katz, D., & Cohn, L. (2021). Flask Web Development : Developing Web Applications
with Python. O’Reilly Media.

34
Netographie

1. OpenAI. API Documentation. Available at : https://beta.openai.com/docs/.

2. Mozilla Developer Network (MDN). JavaScript and Web Development. Available
at : https://developer.mozilla.org/.
3. GitHub. Linguist - Language Detection. Available at : https://github.com/github/
linguist.
4. OWASP. OWASP Cheat Sheet Series. Available at : https://cheatsheetseries.
owasp.org/.
5. React Official Documentation. React : A JavaScript Library for Building User In-
terfaces. Available at : https://reactjs.org/.
6. Axios. Promise based HTTP client for the browser and node.js. Available at : https:
//axios-http.com/.

35