diff --git a/content/projet_programmation/4_besoins/index.md b/content/projet_programmation/4_besoins/index.md
new file mode 100644
index 0000000..d82efef
--- /dev/null
+++ b/content/projet_programmation/4_besoins/index.md
@@ -0,0 +1,112 @@
+---
+title: "PdP: Analyse des besoins"
+date: 2024-01-24
+tags: ["besoins", "analyse", "developpement logiciel"]
+categories: ["Projet de programmation", "Cours"]
+---
+
+Avant même de commencer à coder, il faut analyser les besoins du 
+"commanditaire". Il faut maximiser les chances d'être adéquats mais **sans
+formalisme**, il est cependant **nécessaire** d'y mettre de la rigueur.
+
+Il faut définir et décrire les service que notre logiciel doit offrir, il faut
+aussi identifier et décrire ses différentes contraintes (domaine de
+fonctionnement, usage des ressources forme des résultats, etc.).
+
+Il faut cependant décorréler l'analyse des besoins de l'implémentation. Les
+langages doivent être considéré comme des outils, il faut les choisir en
+fonction des besoins (et non pas faire l'analyse en fonction du langage).
+
+L'analyse doit être effectuée *en langage naturel* de façon précise et avec
+rigueur.
+
+## Deux types de besoins
+
+Nous pouvons commencer par classer les besoins en deux catégories :
+
+ * **Les besoins fonctionnels**: les services et fonctionnalités comme
+   rechercher dans une base de données, réaliser une sauvegarde... Il sont
+   nécessaires au logiciel (*ceux que logiciel devrait faire*);
+ * **Les besoins non-fonctionnels**: caractéristiques de ce que le programma *va
+   faire* comme une réponse rapide de l'interface, la compatibilité avec des
+   formats de fichiers...
+
+Les besoins fonctionnels sont souvent associés à **un verbe**, une action à
+réaliser.
+
+Les besoins non fonctionnels sont souvent critiques et demandent **beaucoup de
+travail**. Ces besoins peuvent aussi être en conflits comme *la rapidité* et la
+*sécurité* par exemple. Ils entraînent souvent des besoins fonctionnels. Ils
+sont eux caractérisés par **un adjectif**.
+
+### Catégoriser des fonctionnalités non fonctionnelles
+
+#### Les besoins non fonctionnels de comportement.
+
+Ils comprennent *les performances*, *la fiabilité*, *la sécurité*, *la facilité
+d'utilisation*, *le domaine d'action*, *la portabilité*
+
+#### Les besoins non fonctionnels organisationnels
+
+Ils comprennent le choix *des processus de développement*, les *langages de
+spécification*, les *techniques de planification du travail*, le *calendrier des
+livrables*, le *cadre budgétaire*.
+
+#### Les besoins non fonctionnels externes
+
+Il dépendent de pré-requis qui ne sont pas dépendants de l'équipe de
+développement. Nous pouvons citer:
+
+ * Les **contraintes matérielles** dépendant de l'architecture matérielle sur
+   laquelle le programme tournera (ISA, espace mémoire, carte graphique, etc.);
+ * Les **contraintes légales** comme les règlement sur les données personnelles,
+   les différents cadres sur les captations vidéos, etc.
+ * Les **contraintes éthiques**: préservation de la vie privée des utilisateur
+   par exemple. 
+
+
+## Autre classement...
+
+Il est aussi possible de classer les besoins entre **utilisateur** et 
+**système**.
+
+Les premiers sont associés à ceux qui vont utiliser le logiciel qu'il soient
+simple utilisateurs, clients, maître d'ouvrage, développeur.
+
+Les seconds sont liés aux contraintes internes du logiciel et ceux qui vont le
+développer (développeur, maître d'œuvre).
+
+Ce type de classement se montre utile lorsque la liste des contraintes est
+longue.
+
+## De la précision ...
+
+Comme nous l'avons vu, l'analyse des besoin se doit d'être précise et
+rigoureuse. Plus elle est précise plus on obtiendra une description adéquate du
+logiciel à produire.
+
+La précision dans l'analyse indique aussi une bonne compréhension du domaine,
+elle permettra une organisation plus efficace du travail.
+
+## ... de la vérification ...
+
+Un besoin doit ouvoir être testé et vérifié sinon il est ineffectif. 
+
+oin qui ne peux pas être vérifié et/ou testé  doit être décomposé en
+sous-besoins (ou être précisés).
+
+Prenons l'exemple: *importer des fichiers*. Ce besoin n'est pas vérifiable,
+validable et testable en l'état. Nous pouvons le décomposer:
+
+ * Lire des types de fichiers distinct, mais il faut décrire lesquels;
+ * Associer des traitements à chacun des types de fichiers;
+ * Ajouter les types de fichiers acceptés dans l'interface;
+ * etc.
+
+Un bon exemple de décomposition reste les options associés à la commande `ls`.
+
+## ... et de la caractérisation
+
+En plus de la décomposition, il est important de **caractériser** un besoin en
+le qualifiant et l'associant à des *domaines de fonctionnements stricts*, à des
+*contraintes de faisabilités*, etc.
diff --git a/content/reseaux_protocoles/2_couche_applicative/index.md b/content/reseaux_protocoles/2_couche_applicative/index.md
new file mode 100644
index 0000000..fb70e6c
--- /dev/null
+++ b/content/reseaux_protocoles/2_couche_applicative/index.md
@@ -0,0 +1,195 @@
+
+---
+title: "Réseaux et Protocole: couche applicative"
+date: 2024-01-22
+tags: ["OSI", "application"]
+categories: ["Réseaux et protocoles", "Cours"]
+mathjax: true
+---
+
+On parle ici des protocoles utilisé par les applications comme *SMTP*, *HTTP*,
+*DNS*, *IMAP*, etc. On se place au niveau **application** du modèle *TCP* ou de
+l'ensemble des couches 4 à 7 du modèle *OSI*. Ici il n;est pas question pour les
+dévellopeur de programmer pour le cœur de réseau, mais pour la périphérie.
+
+## Modèle client-serveur
+
+Comme indique le titre, nous avons deux types d'acteur :
+
+ * **le serveur**: il est toujours actif avec une adresse IP fixe. La plupart du
+   temps il est dans un *datacenter*;
+ * **le client**: il communique avec le serveur uniquement lorsqu'il en a
+   besoin. Le client n'a pas besoin d'adresse IP fixe. C'est lui qui contacte le
+   serveur qui en reponse lui répondra. Les clients n'échangent pas entre eux.
+
+## Modèle P2P
+
+Ici les clients peuvent aussi faire office de serveurs. Les équipements
+terminaux sont aussi **connectés entre eux**. C'est une architecture
+*distribuée* et *auto-scalable*. La gestion des **peers** est complexe.
+
+Dans ce cas il y a deux processus (un serveur et un client) sur la même machine.
+
+## Communication inter-processus
+
+Dans le cadre de programmes qui s'exécutent sur un même équipement, on utilisera
+les mécanismes de communication inter-processus.
+
+Avec des processus répartis sur des machines differentes, les messages sont
+acheminées via le réseau. On utiliseta alors les mécanismes de *sockets*.
+
+## Les sockets
+
+C'est une passerelle entre les couches transport et applications. C'est une
+porte d'envoi / réception de données pour les processus.
+
+## Adressage
+
+La couche réseaux (3) esr représentée par une adresse IP 32 bis en v4 (et 128 en
+v6). Mais cette adresse ne suffit pas pour identifier le processus qui demande 
+les données. Il faut alors le **numéro de port**.
+
+Ces numéros vont de 0 à 65535, les 1024 premiers sont normalement réservés pour
+les serveurs, le reste pour les clients.
+
+## Besoins spécifiques des applications
+
+Les applications n'ont pas toutes les mêmes besoins en ce qui concerne les
+données envoyées ou reçues via un réseau informatique
+
+La VoIP, ou encore le streaming audio / vidéopeuvent se passer des **contrôles
+d'intégrité** par exemple. mais la VoIP elle nécessite d'utiliser des
+communication **temps réel** (ou de s'en approcher) tout comme le jeu en ligne.
+
+## La couche transport
+
+Nous avons ici deux protocoles utilisés:
+
+### TCP
+
+C'est un protocole avec connexion qui vise avant tout **la fiabilité** :
+contrôle de flux, gestion de la congestion, réordonancement des paquets. Avant
+d'acheminer des données, il est nécessaire de lancer une connexion en 3 étapes
+(`SYN`, `SYN-ACK`, `ACK`). Il est aussi nécessaire de mettre fin explicitement 
+à la connexion (`FIN`). Cependant il **n'y a pas de gestion du timing** ni de
+**sécurité**.
+
+#### La sécurité dans TCP
+
+Comme nous l'avons vu il n'y a pas de gestion de la sécurité dans *TCP*. Mais il
+existe une couche intermédiaires entre les couches *application* et *transport*
+: TLS pour **Transport Layer Security**.
+
+*TLS* se charge de l'authentification, du chiffrement, et du contrôle de
+l'intégrité.
+
+### UDP
+
+Ici il n'y a pas de gestion de fiabilité (ordre, sommes de contrôle,
+acquittement, etc.). En contrepartie il y a peu *d'overhead*, il est donc adapté
+our la VoIP par exemple. Il est aussi plus simple à implémenter et supporte le
+*multicast* et le *broadcast*.
+
+## Quelques protocoles
+
+### HTTP
+
+C'est le protocole utilisé pour le **web**, il se base sur *TCP* et les
+mécanismes de connexions sous-jacent. Il est de type client - serveur:
+
+ * client: *User Agent*, le navigateur web;
+ * serveur: serveur HTTP comme Apache ou Nginx.
+
+Le serveur stocke des objets (fichiers HTML, images, vidéos etc.)
+
+Il existe deux type de connexions HTTP : 
+
+ * persistente: 1 connexion pour transférer plusieurs objets;
+ * non persistente: 1 connexion pour tranférer un objet.
+
+#### La requête
+
+Elle emmane du client à destination du serveur, la requête est formatée en
+ASCII, elle contient une requête suivi d'élément d'entête:
+
+```
+GET https://ent.u-bordeaux.fr HTTP/2\r\n
+```
+
+Ici on demande `https://ent.u-bordeaux.fr` en HTTP version 2. Les entêtes peuven
+contenir les langies acceptés par le client par exemple.
+
+#### La réponse
+
+Elle contient le code de retour, les entêtes de réponse ainsi que le contenu. La
+réponse peut être conditionnée à la modification de la ressource demandée via un
+*conditionnal GET*. L'entête de la demande contient le champs 
+`If-Modified-Since`. Le serveur peut alors répondre avec un code `304`
+`Not-Modified` et le navigateur utilisera la version dans son cache.
+
+#### Amélioration du protocole
+
+La verion 2 de HTTP permet de découper les ressources demandées en *chunk* et de
+réaliser des envois entrelacés. Ainsi les gros fichiers ne pénalisent pas le
+transfert des plus petits (mécanismes de `first come first served*.
+
+La version 3 propose d'utiliser les protocole UDP et QUIC. Il propose de gérer
+la réupération de paquets perdus (hé oui, il utlise UDP), il propose aussi la
+gestion de la congestion et plus de sécurité (QUIC).
+
+### DNS
+
+C'est le protocole chargé de la résolution des noms de domaines (et des
+résolutions inverses). Il fait le lien entre les adresses IP et les noms de
+domaines. C'est **une base de donnée distribuée** our éviter le *single point
+of failure*
+
+La base de données est hiérarchisée : `Root server` -> `Top level domain` ->
+`authoritative server` -> `recursive resolver`.
+
+
+Deux types de requêtes:
+
+ * **itérative**: le résolveur a la charge de la requête et demande les
+   informations du *root* jusqu'au serveur *authoritative*;
+ * **recursive**: chaque serveur est responsable de sa réponse. La requête va
+   ainsi passer de serveur en serveur et faire le chemin inverse jusqu'à revenir
+   au client.
+
+#### Les enregistrement DNS et les messages
+
+Il sont au format RR *Ressource Record*:
+
+```
+<nom> <valeur> <type> <TTL>
+```
+
+Les messages du serveur vers le client contiennent le nombre de question, le
+nombre de réponse et enfin les réponses.
+
+## Retour sur les sockets
+
+Comme nous l'avons vu elle serve de point de liaisons entre les applications et
+la couche transport. Elle sont créees par le système.
+
+Pour la création de socket UDP :
+
+```c
+mysock = socket(AF_INET, SOCK_DGRAM);
+mysock.rcevfrom();
+mysock.sendto();
+bind(mysock, &addr, sizeof(addr));
+```
+
+C'est relativement simple car il n'y a pas de connexion.
+
+Pour TCP c'est un peu plus complexe:
+
+```c
+mysock = socket(AF_INET, SOCK_STREAM);
+mysock.listen();
+mysock.connect(addr, port);
+
+// Accept connection result a new one!
+newsocks = mysock.accept();
+```