diff --git a/assets/admin-runners.png b/assets/admin-runners.png
new file mode 100644
index 0000000000000000000000000000000000000000..fb2362c6f9032429b2e3d6932f3ade5b4cf78bed
Binary files /dev/null and b/assets/admin-runners.png differ
diff --git a/assets/gitea-full-repo.png b/assets/gitea-full-repo.png
new file mode 100644
index 0000000000000000000000000000000000000000..465405050a634ab8a0760339dc82d3971874bc1a
Binary files /dev/null and b/assets/gitea-full-repo.png differ
diff --git a/assets/gitea-home.png b/assets/gitea-home.png
new file mode 100644
index 0000000000000000000000000000000000000000..e089c9fb334e845e05ea5d9c85f792de72f0aa0e
Binary files /dev/null and b/assets/gitea-home.png differ
diff --git a/assets/gitea-new-repo.png b/assets/gitea-new-repo.png
new file mode 100644
index 0000000000000000000000000000000000000000..82864d76634dd0574a8c669d1c8e5715871f57e0
Binary files /dev/null and b/assets/gitea-new-repo.png differ
diff --git a/assets/gitea-profile.png b/assets/gitea-profile.png
new file mode 100644
index 0000000000000000000000000000000000000000..4513aae3d4802d22932692e1ed998c4efe587588
Binary files /dev/null and b/assets/gitea-profile.png differ
diff --git a/assets/gitea-register.png b/assets/gitea-register.png
new file mode 100644
index 0000000000000000000000000000000000000000..66596df925cc5726f83a956e8e71bfc3d87396a8
Binary files /dev/null and b/assets/gitea-register.png differ
diff --git a/assets/gitea-repo.png b/assets/gitea-repo.png
new file mode 100644
index 0000000000000000000000000000000000000000..9a4857f4b91251ddd9af417d564833247495912a
Binary files /dev/null and b/assets/gitea-repo.png differ
diff --git a/src/Gitea.md b/src/Gitea.md
index ff1c59b794c794b5b31b8e701cab6429a684992d..ba96e80ac5efe4fe6cd8c7d049c655712980c298 100644
--- a/src/Gitea.md
+++ b/src/Gitea.md
@@ -162,4 +162,162 @@ docker-compose pull
 docker-compose up -d
 ```
 
-Et tout est mis à jour automatiquement. 
\ No newline at end of file
+Et tout est mis à jour automatiquement. 
+
+# Tests d'utilisation
+
+Il est maintenant temps de tester notre installation en essayant d'utiliser le service Gitea disponible sur le port 3000.
+
+Commençons donc par créer un nouvel utilisateur à partir de l'interface.
+
+![Page d'accueil de Gitea](assets/gitea-home.png)
+
+![Inscription d'un nouvel utilisateur](assets/gitea-register.png)
+
+On arrive donc dans notre page de profil, où il n'existe pour l'instant aucun dépôt. Crééons-en donc un !
+
+![Page de profil vierge Gitea](assets/gitea-profile.png)
+
+Créons donc un nouveau dépôt pour y déposer la source des rapports de cette SAÉ.
+
+On commence donc par cliquer sur + > Nouveau dépôt. On entre le nom du dépôt (ici, ce sera les rapports pour S2.03), une description si besoin, puis on clique sur "Créer" pour finaliser la création du dépôt. Exactement comme sur Gitlab ou GitHub.
+
+![Nouveau dépôt sur Gitea](assets/gitea-new-repo.png)
+
+On arrive ainsi sur une nouvelle page indiquant que le nouveau dépôt est crée.
+
+On souhaite maintenant y ajouter du code. Il est l'heure de **manipuler un peu le terminal de la machine hôte**.
+
+Comme le dépôt local existe déjà, et possède déjà une **remote**, qui pointe vers le serveur Gitlab de l'université, il faudra simplement en ajouter une nouvelle
+
+```bash
+git remote add gitea http://10.21.215.74:3000/robert/S2.03
+``` 
+Une fois cela fait, on peut simplement envoyer les modifications sur gitea.
+
+```
+git push gitea main
+```
+
+L'argument `gitea` indique que l'on souhaite bel et bien envoyer le code sur la remote `gitea`, que l'on vient juste de créer.
+
+Git nous demande d'entrere un nom d'utilisateur ainsi qu'un mot de passe pour l'authentification, et une fois cela entré, il suffit d'attendre et de valider l'envoi des changements sur le serveur distant. 
+
+Une fois cela fait, on met simplement à jour la page, et on a cette fois-ci accès au code complet de la SAÉ.
+
+![Le dépôt S2.03 une fois les changements envoyés](assets/gitea-full-repo.png)
+
+Tout ceci semble fonctionner plutôt bien. On peut donc affirmer que le serveur Gitea est opérationnel et fonctionne bien.
+
+# CI/CD, Actions : Pour aller plus loin
+
+Les hébergeurs de code Git intègrent souvent des outils d'intégration et déploiement en continu (CI/CD pour Continuous Integration/Continuous Deployment). 
+
+## Définitions et principes
+
+L'**intégration continue** consiste à automatiquement intégrer des modifications de code dans un dépôt partagé (ex: dépôt git), et à compiler et tester automatiquement le logiciel pour s'assurer qu'il continue de fonctionner comme prévu.
+
+Le **déploiement continu**, dans le même temps, est la pratique consistant à déployer (compiler et envoyer en *release*) automatiquement de nouvelles versions du projet une fois qu'elles ont **passé les étapes de construction et de test** (intégration). Cela permet de publier plus rapidement les nouvelles fonctionnalités, pour **éviter de devoir tout faire manuellement**.
+
+### Pipeline CI/CD
+
+L'intégration continue et le déploiement continu réunis s'appellement **le pipeline CI/CD**. Il s'agit d'une combinaison d'outils (au sens informatique du terme, donc des *commandes*), de pratiques et de processus qui **fonctionnent ensemble pour intégrer, tester, et déployer en continu les changements de code**.
+
+Sa mise en oeuvre passe souvent par plusieurs pratiques : 
+ - Compilation automatique de code dans des environnements contrôlés (machines virtuelles)
+ - Tests du projet, donc à la fois des tests unitaires, et fonctionnels (exécution surveillée du projet dans des conteneurs automatisés pour vérifier son bon fonctionnement)
+ - Publication automatisée des nouvelles versions sur le serveur de distribution.
+
+La raison pour laquelle les plateformes de gestion de code intègrent souvent ces ensembles d'outils est leur **grande omnipotence**. En effet, la plupart de ces plateformes réunissent :
+ - Un dépôt partagé de code
+ - Une documentation éditable (wiki)
+ - Un système de distribution de versions fixes (tags, releases)
+ - Pour certains, un serveur web (GitHub Pages, Gitlab Pages).
+Il est donc parfaitement logique que ces plateformes mettent à disposition un système permettant de **relier cet ensemble d'outils via du scripting**.
+
+## Utilisation sur Gitea
+
+Fort heureusement, Gitea possède tout ce qu'il faut, par le biais de ses *Actions* (comme sur GitHub), pour faire fonctionner des pipelines basiques de CI/CD.
+
+### Installation du *runner*
+
+La première étape consiste à installer un *runner*. Il s'agit d'un programme ayant pour but d'exécuter des commandes, afin de mener à bien des tâches automatisées. 
+
+#### Téléchargement de `act_runner`
+
+Il faut donc tout d'abord récupérer un `act_runner` depuis la [page des releases officielle](https://gitea.com/gitea/act_runner/releases). Il existe une bonne quantité de choix de binaires, suivant le système d'exploitation et l'architecture du processeur de la machine hôte. Nous choisirons ici `act_runner-linux-arm64`. 
+
+L'idée est de placer ce programme dans un endroit où le service Gitea pourra y avoir accès. Il servira à exécuter toutes les commandes des pipelines CI/CD.
+
+Le "home directory" `~` de l'utilisateur `git` fera parfaitement l'affaire. 
+```bash
+# Connection en tant que git
+su - git
+cd ~
+
+# Téléchargement de l'act_runner
+wget https://gitea.com/gitea/act_runner/releases/download/v0.2.11/act_runner-0.2.11-linux-arm64
+mv act_runner-0.2.11-linux-arm64 act_runner
+
+# Ajout des permissions exécutable et vérifications
+chmod +x act_runner 
+./act_runner --version
+```
+#### Enregistrement du programme 
+
+Pour permettre à Gitea d'utiliser `act_runner`, il faut tout d'abord **récupérer un token d'enregistrement**. 
+
+Connectons-nous à notre utilisateur Gitea (le premier crée, l'administrateur), et rendons-nous à cette adresse :   
+> `https://localhost:3000/-/admin/actions/runners`
+
+On a alors accès à la page d'administration des actions, depuis laquelle on peut obtenir une liste de runners enregistrés.
+
+![Administration - runners Gitea](assets/admin-runners.png)
+
+Pour en créer un, il faut lui passer un **token d'enregistrement**, qu'on vient récupérer ici.
+
+En haut à droite, cliquer sur le bouton bleu **Créer un nouvel exécuteur**, et copier le champ "registration token" qui s'affiche.
+
+On retourne ensuite dans le terminal, et on entre : 
+
+```bash
+# Enregistrement du runner
+./act_runner register
+```
+
+On entre ensuite simplement le token copié plus tôt, et le tour est joué !
+
+*(Source : [Gitea Documentation](https://docs.gitea.com/usage/actions/act-runner))*
+
+### Utilisation des Gitea Actions
+
+Les Gitea Actions fonctionnent de manière assez similaire à celles de GitHub ou à Gitlab CI, c'est-à-dire avec un fichier `.yml`, dont voici un exemple :
+
+```yml
+name: Gitea Actions Demo
+run-name: ${{ gitea.actor }} is testing out Gitea Actions
+on: [push]
+
+jobs:
+  Explore-Gitea-Actions:
+    runs-on: ubuntu-latest
+    steps:
+      - run: echo "The job was automatically triggered by a ${{ gitea.event_name }} event."
+      - run: echo "This job is now running on a ${{ runner.os }} server hosted by Gitea!"
+      - run: echo "The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}."
+      - name: Check out repository code
+        uses: actions/checkout@v4
+      - run: echo "The ${{ gitea.repository }} repository has been cloned to the runner."
+      - run: echo "The workflow is now ready to test your code on the runner."
+      - name: List files in the repository
+        run: |
+          ls ${{ gitea.workspace }}
+      - run: echo "This job's status is ${{ job.status }}."
+```
+
+À l'instar de GitHub, il suffit de placer ce fichier dans `.gitea/workflows/exemple.yml`, et les changements seront **automatiquement pris en compte**.
+
+Le workflow sera ainsi exécuté selon le fichier YML à chaque push.
+
+*(Source : [Gitea Documentation](https://docs.gitea.com/usage/actions/quickstart))*
+