diff --git a/qualification/presentation/img/pyramidetestsapplicatifs.png b/qualification/presentation/img/pyramidetestsapplicatifs.png
new file mode 100644
index 0000000..cf818a0
Binary files /dev/null and b/qualification/presentation/img/pyramidetestsapplicatifs.png differ
diff --git a/qualification/presentation/ressources/qualification.epgz b/qualification/presentation/ressources/qualification.epgz
new file mode 100644
index 0000000..4fdaf51
Binary files /dev/null and b/qualification/presentation/ressources/qualification.epgz differ
diff --git a/qualification/presentation/slides.md b/qualification/presentation/slides.md
new file mode 100644
index 0000000..ac09541
--- /dev/null
+++ b/qualification/presentation/slides.md
@@ -0,0 +1,266 @@
+<style>pre, table { font-size: 0.6em !important; }</style>
+
+# Qualification et intégration continue
+
+William Petit - S.C.O.P. Cadoles
+
+---
+<!-- page_number: true -->
+
+## Qu'est ce que la qualification ?
+
+---
+
+## Qu'est ce que l'intégration continue ?
+
+---
+
+## Les tests applicatifs
+
+Les tests applicatifs ont pour objectif de valider le bon fonctionnement de l'application d'un point de vue métier, c'est à dire de vérifier que celle ci répond aux attentes et aux contraintes du client d'un point de vue fonctionnel.
+
+---
+
+## La pyramide des tests applicatifs
+
+![center 70%](./img/pyramidetestsapplicatifs.png)
+
+---
+
+## Tests unitaires
+
+---
+
+## Objectifs
+
+Tester le bon fonctionnement des plus petites unités logiques/fonctionnelles de l'application: les fonctions/méthodes d'objets.
+
+---
+
+## Cycle de vie
+
+1. Définir le comportement attendu de la classe/fonction à implémenter.
+2. Créer le cas de test validant ce comportement.
+3. Exécuter le test. Il ne devrait pas être passant, l'implémentation étant incomplète à ce stade.
+4. Implémenter la fonction/classe pour que le test soit passant.
+
+---
+
+## Caractéristiques clés
+
+- Ils sont nombreux.
+- Ils sont mis en place dès le début de l'implémentation, voir avant.
+- Ils sont rapides à exécuter.
+- Ils permettent de détecter rapidement les régressions.
+- Ils permettent de rassurer le développeur qui doit apporter des évolutions à une base de code existante.
+- Ils s'exécutent en continu sur le poste du développeur et à chaque changement sur le serveur de gestion des sources.
+- Ils ne devraient pas nécessiter de dépendances externes.
+
+---
+
+## Exemple: Tests unitaires en Javascript (Mocha)
+
+TODO
+
+---
+
+## Exemple: Tests unitaires en PHP (Symfony3)
+
+TODO
+
+---
+
+## Exercice: Tests unitaires d'une fonction de validation d'un numéro de carte bancaire en Javascript
+
+Soit un numéro de carte bancaire donné, implémenter un test pour la fonction validant le code de celle ci PUIS implémenter la fonction qui permet de valider ce code.
+
+**Ressources**
+
+- [La formule de Luhn](https://fr.wikipedia.org/wiki/Formule_de_Luhn)
+
+
+---
+
+## Tests d'intégration
+
+---
+
+## Objectifs
+
+Tester la bonne communication des différents "modules" composant une application.
+
+---
+
+## Caractéristiques clés
+
+- Ils sont moins nombreux que les tests unitaires.
+- Ils peuvent prendre un peu de temps à s'exécuter.
+- Ils sont mis en place au cours de l'implémentation initiale et maintenus au fur et à mesure de l'évolution de l'application.
+- Ils peuvent nécessiter des dépendances externes, mais généralement pas l'ensemble de l'infrastructure.
+- Ils peuvent nécessiter des données d'amorçage.
+- Ils impliquent souvent la mise en place de composants "factices" pour simuler une partie de l'application.
+- Ils s'exécutent à la demande sur le poste du développeur et sur le serveur d'intégration continue à intervalles réguliers.
+
+---
+
+## Cycle de vie
+
+Les tests d'intégration devraient être abordés (en général) en seconde moitiée d'itération, au moment de la finalisation des modules applicatifs prêts à être livrés.
+
+Ils devraient cibler en premier les modules critiques de l'application, notamment ceux ayant pour rôle de contrôler/valider le cycle de vie des données métiers.
+
+Les tests d'intégration peuvent être un bon témoin/validateur de l'état de réussite d'une itération.
+
+---
+
+## Exemple: Test de la soumission d'un formulaire (Symfony3)
+
+TODO
+
+---
+
+## Tests fonctionnels
+
+---
+
+## Objectif
+
+Tester le bon fonctionnement de l'application d'un point de vue utilisateur.
+
+---
+
+## Caractéristiques clés
+
+- Ils devraient être les moins nombreux de l'ensemble des tests applicatifs.
+- Ils devraient être représentatifs des cinématiques d'action des utilisateurs.
+- Ils devraient s'exécuter sur un environnement identique à la production.
+- Ils sont souvent complexes à mettre en place/maintenir.
+- Ils ont une couverture fonctionnelle très large mais ne permettent pas d'identifier directement les sources de dysfonctionnement.
+- Ils devraient couvrir les procédures faisant intervenir les dépendances externes de l'application (serveur de courriel, API externes, base de données...).
+
+---
+
+## Cycle de vie
+
+Les tests fonctionnels devraient être implémentés une fois que l'itération a été validée par le client.
+
+Ils ne devraient être modifiés que lorsque le client demande une évolution de l'interface utilisateur et/ou des cinématiques d'action.
+
+---
+
+## Exemple: Tests fonctionnels Web avec NightmareJS
+
+TODO
+
+---
+
+## Exercice: Tester une procédure d'authentification d'un utilisateur 
+
+TODO
+
+---
+
+## Les tests "techniques"
+
+Les tests techniques ont pour objectif de valider le bon fonctionnement de l'infrastructure exécutant l'application, c'est à dire que l'application et son infrastructure seront capables de répondre au contexte d'usage en production.
+
+---
+
+## Tests de charge
+
+---
+
+## Objectif
+
+Les tests de charge doivent permettre de valider le niveau de stabilité de l'infrastructure et de l'application par rapport à la volumétrie d'utilisateurs en production et son contexte technique d'utilisation.
+
+Pour ce faire, la mise en place d'une stratégie concrète de métrologie est **obligatoire**.
+
+---
+
+## Caractéristiques clés
+
+- Ils nécessitent la mise en place d'une infrastructure identique (ou au plus proche) à la production.
+- Les données produites sont souvent peu fiables car les tests de charge véritablement représentatifs d'un comportement d'un utilisateur sont complexes à mettre en place.
+- Ils doivent couvrir toutes les briques techniques de l'infrastructure et de l'application: disques, réseau, mémoire vive, CPU, serveur HTTPS, serveur applicatif, base de données...
+
+---
+
+## Cycle de vie
+
+Les tests de charge devraient être effectués avant tout primo déploiement d'une application et réactualisés lorsque le contexte d'usage de celle ci change (exemple: bascule d'un usage local à un usage national).
+
+Les tests de charge devraient être exécutés régulièrement afin de vérifier qu'aucun "goulot d'étranglement" n'a été introduit dans l'itération en cours.
+
+---
+
+## Exemple: Utilisation d'Apache Benchmark pour vérifier le temps de réponse d'une application Web
+
+---
+
+## Tests de sécurité
+
+---
+
+## Objectif
+
+Valider la conformité de l'infrastructure et de l'application d'un point de vue sécurité. Découvrir des vulnérabilités dans la conception de l'application.
+
+---
+
+## Caractéristiques clés
+
+- Ils sont complexes à mettre en place
+- Ils doivent fonctionner sur un environnement identique à la production.
+- Ils ne peuvent remplacer un audit de sécurité "manuel".
+- Ils sont souvent peu efficaces pour détecter les failles qui nécessites un premier niveau d'accréditation.
+
+---
+
+## Cycle de vie
+
+Ils doivent être mis en place au plus tôt dans le cycle de développement.
+
+Suivant le type de cible, ils peuvent être exécutés de différentes manières: à chaque fin d'itération, de manière règulière, etc...
+
+Ils doivent être réactualisés lors de tout changement d'infrastructure et de socle technologique de l'application.
+
+---
+
+## Exemple: Vérification de sécurité pour les dépendances PHP
+
+TODO https://github.com/sensiolabs/security-checker
+
+---
+
+## Exemple: Tests d'attaques automatisées sur les applications Web avec w3af
+
+TODO https://tools.kali.org/web-applications/w3af
+
+---
+
+## Les serveurs d'intégration continue
+
+---
+
+## Technologies de conteneurisation
+
+---
+
+## Présentation de Docker
+
+---
+
+## Exemple: Gitlab et Gitlab Runner
+
+---
+
+## Exercice: Mise en application générale
+
+---
+
+# Licence
+
+## CC BY-NC-SA 3.0 FR
+
+[Creative Commons - Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 3.0 France](https://creativecommons.org/licenses/by-nc-sa/3.0/fr/)