Commit initial - Manque des cours et tout est moche
This commit is contained in:
commit
666d18f8f1
6
.gitignore
vendored
Normal file
6
.gitignore
vendored
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
media
|
||||
Projet
|
||||
trash
|
||||
Mémoire.md
|
||||
.owncloudsync.log
|
||||
notes.sqlite
|
||||
41
Cours Archi Client-Serveur/Cours 3.md
Normal file
41
Cours Archi Client-Serveur/Cours 3.md
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
Cours 3
|
||||
========================
|
||||
|
||||
RMI : client/serveur en java. C'est un peu vieux mais ça permet de comprendre comment ça fonctionne. Les autres (suivants) sont globalement basés sur la même philosophie.
|
||||
|
||||
Se concentrer sur la communication plus que sur le traitement.
|
||||
|
||||
|
||||
# CORBA
|
||||
|
||||
Même philosophie que RMI
|
||||
|
||||
Architecture d'objets distribués (voir pdf) => architecture global. Principe de fonctionnement est celui de RMI : client /serveur - appelant / appelé . L'objectif est de pouvoir assurer cette communication, come pour RMI
|
||||
|
||||
Architecture :
|
||||
|
||||
* Notion de client et de serveur
|
||||
* Couche TCP IP
|
||||
|
||||
Chacun fait ce qu'il veut avec les objets. L'idée est que chaque demande se fasse dans un langage générique. On implémente un BUS logiciel (ORB) dans lequel on fait passer demandes. Dedans on a un traducteur qui traduit demande en un format générique et véhicule au serveur qui retraduit. Les adaptateurs qui font la traduction sont les OA
|
||||
Y a toujours besoin d'une interface qui permet de savoir tout ce qu'on peut implémenter. Ici c'est IDL, un fichier texte dans un langage particulier qui implémente l'interface. Ce fichier est partagé par client et serveur.
|
||||
À partir IDL => projection pour récupérer (implémenter ?) interface, chacun à sa façon selon client ou serveur. IDL se compose de 6 fichiers
|
||||
On a aussi un daemon (daemon ORB = orb ), même fonctionnement qu'ailleurs, en tache de fond il orchestre communications
|
||||
|
||||
|
||||
On doit définir un module pour chaque "élément" (à préciser) on peut pas en envoyer seuls
|
||||
```
|
||||
Module {
|
||||
Interface {
|
||||
Attributs : type nom options;
|
||||
Méthodes : type retour, statut, nom, paramètres type de passage (in ou out ou inout en entré en sortie ou les deux)
|
||||
}
|
||||
}
|
||||
```
|
||||
Tout modification a niveau de l'objet implique une régénération complète : on évite donc !
|
||||
|
||||
Ordre de démarrage :
|
||||
|
||||
* orbd
|
||||
* serveur
|
||||
* client
|
||||
8
Cours Archi Client-Serveur/Cours 4.md
Normal file
8
Cours Archi Client-Serveur/Cours 4.md
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
Cours 4
|
||||
========================
|
||||
|
||||
Ajd TP CORBA
|
||||
Pour juin, TP à faire (seul à priori) sur une archi au choix. Choisir si on prned TP Guillaume est une grosse merde puante ou bien si on fait un exam classique. + exam écrit à la fin dnas tous les cas.
|
||||
|
||||
Rappels sur CORBA
|
||||
|
||||
4
Cours Conduite projet/Cours 3.md
Normal file
4
Cours Conduite projet/Cours 3.md
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
Cours 3
|
||||
========================
|
||||
|
||||
|
||||
54
Cours Conduite projet/Cours 4.md
Normal file
54
Cours Conduite projet/Cours 4.md
Normal file
|
|
@ -0,0 +1,54 @@
|
|||
Cours 4
|
||||
========================
|
||||
|
||||
## Toujours envie de crever
|
||||
|
||||
Je sais pas trop de quoi il parle. Le fait de s'en foutre n'aide pas.
|
||||
Le chef de projet est un "vendeur" : il vend une organisation, une synchronisation de ressources, de moyens, mais surtout un projet et une rentabilité sur ce projet.
|
||||
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah tuez-moi putain aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah !
|
||||
|
||||
Il vend aussi son expérience, son cerveau, son cul, sa mère, bref, c'est un vendu.
|
||||
|
||||
Surtout ne jamais mettre d'affect, de passionnel. Rester sur du factuel.
|
||||
Attention aux étrangers qui n'ont pas la même culture, notamment de projet, que nous. Toujours fair un écrit qui résumera une conf call ou réunion. Pas qu'avec les étrangers d'ailleurs, il a probablement pris cet exemple parce que c'est un gros beauf stupide et prétencieux. Genre il aime bien dire "culture" parce que ça l'aide à se sentir intelligent. Mais bon quand on voit son morne oeil de bovin on sait que c'est du fake.
|
||||
Mais c'est vrai que l'écrit permet de s'assurer que les choses seront faites. Certaines personnes (appelons les les branlots), ne feront rien de ce qui a été dit oralement, mais uniquement ce qui a été posé par écrit (bien obligés de le faire).
|
||||
|
||||
L'utilisateur principal est en charge de faire la liste des besoins fonctionnels, de mettre en place les tests et de suivre les jeux de test.
|
||||
L'acheteur est celui qui fait vivre la boite.
|
||||
|
||||
Le chef d'équipe gère les tema en chagre du dev et recup les livrables qu'il fournit au chef de projet
|
||||
L'assurance projet c'est simplement qu'on part du principe qu'on peut pas être dsqf partout
|
||||
|
||||
Il va contrôler les séquences, les sections, les rapports produits, et aussi la fin du projet. Mais je sais pas qui.
|
||||
|
||||
## Après la pause
|
||||
|
||||
Il repart dans ses délires de schéma.
|
||||
|
||||
Le mandataire commande au
|
||||
|
||||
comité de pilotage qui contient :
|
||||
utilisateur principal / Executif / Fournisseur principal
|
||||
|
||||
Le comité donne une autorisation au Chef de projet (toléranc des séquences), lui- même donne une autorisation des lots de travail au Chef d'équipe (tolérance)
|
||||
Le chef d'équip remonte au CP un rpaport de point de controle. Le CP remonte au comité de pilotage un rapport d epoint clé, un rapport de séquence et un raport d'exception
|
||||
|
||||
Le boulot du CP c'est, en boucle : Planifier > Controler > Surveiller
|
||||
|
||||
Il faut s'avoir s'adapter à l'environnement : dans certains pays, la gestion des aléas va re plus importante qu'ailleurs. Les conditions météos puvent par exemple jouer. Ex en Afrique, trop chaud à certaines heures, on va bosser que matin (et soir ? ).
|
||||
Encore et toujours il faut savoir gérer ses risques : il parle de la grève (oulala y doit pas trop trop aimer les syndicats le père Seimann). **Établir une liste de risques**
|
||||
Cete liste de risques il faut la compléter ensuite en disant si le risque est fort, leur statut (déclaré, passé pas arrivé etc), ainsi que comment on va le gérer. c'est une boite à outils qu'on se constitue.
|
||||
|
||||
allez encore un schéma à la con :
|
||||
|
||||
On démarre avec l'identification ud risque
|
||||
Puis évaluation du risque
|
||||
Pis valorisation du risque (avec étude d'impact)
|
||||
ensuite identification des réponses
|
||||
Sélection de la réponse
|
||||
Planifier et ressources
|
||||
Enfin supporter et rapporter
|
||||
qui revient soit à identification soit à évaluation du risque (début)
|
||||
|
||||
Trouver l'équilibre entre coût de la sécurité et probabilité et impact du risque.
|
||||
128
Cours Conduite projet/Cours 5 2018-04-20T13_17_29.md
Normal file
128
Cours Conduite projet/Cours 5 2018-04-20T13_17_29.md
Normal file
|
|
@ -0,0 +1,128 @@
|
|||
Cours 5
|
||||
========================
|
||||
|
||||
|
||||
## Gestion des risques
|
||||
|
||||
Le principe est de vérifier que le produit machin les risqus toussa et détecter les malfaçons et de valider et approuver le produit si on est dnas le cas d'une livriason
|
||||
Il y a donc des avantages a avoir un maitre qualité, mais ça a aussi des inconvéients genre les coûts. La revu qualité donne une vraie mesure sur l'avancement du projet et de mettre de la confiance.
|
||||
La cellule qualité permet aussi de s'assurer qu'on va toujours s'améliorer. On implique sérieusmeent la team projet.
|
||||
|
||||
## Gestion des configurations
|
||||
|
||||
C'est le sixième composant. aucune idée de composants de quoi. Ni de qui sont les 5 autres.
|
||||
il parle de ITIL et Prince2 (Lu ?)
|
||||
C'est gérer le versionning du produit.
|
||||
|
||||
|
||||
## Gestion du changement
|
||||
|
||||
On a définir un cadre et en fonction de ce cadre définir gestion du changement adapté pour intégrer ce qu'on a à intégrer en fonctionnalités.
|
||||
|
||||
|
||||
Pour **Prince2** il y a 3 type d'incidents : (oups pu écouté)
|
||||
|
||||
quand on a des problèms enre techniques pas prévus, on utilise le budgt de contingence, prévu par le chef de projet en cas d'iprévus.
|
||||
|
||||
Dans la gestion des problème y a 6 étape
|
||||
|
||||
- détecter
|
||||
- catégoriser
|
||||
- analyser
|
||||
- enquéter sources pour empécher reproduction
|
||||
- documenter (se)
|
||||
- mettre à jour recueil incidents et clui des risques
|
||||
|
||||
on voit avec chef de projet, comité de pilotage et eventuellement d'uatres gus lis au problème => quasiment pareil qu'ITIL
|
||||
|
||||
connaitre impact sur équipe, sur planning (ça prend du temps) possibilité de faire un rollback, est ce que ça a impact sur :
|
||||
|
||||
- projet
|
||||
- gestion des risques
|
||||
|
||||
# Sans titre
|
||||
|
||||
voir schéma sur cours
|
||||
|
||||
|
||||
|
||||
**Elaboration du projet :**
|
||||
|
||||
- nommer un responsable proj
|
||||
- constituer une ou plusieurs équipes construction
|
||||
- nommer équipe de gestion proj
|
||||
- préparer un exposé du projer
|
||||
- définir une approche projet
|
||||
- préparer l'étape d'initialisation
|
||||
|
||||
|
||||
**Initialisation du projet :**
|
||||
- objectif finaliser contrat entre glkjs et posifdlkgj
|
||||
6 sous étapes :
|
||||
- planifier la qualité
|
||||
- mise en place des dossiers du projet
|
||||
- assembler les documents d'initialisation du projet
|
||||
|
||||
**Diriger un projet (DP 1 à 5)**
|
||||
objectifs :
|
||||
gérer ls sous
|
||||
gestion quotidienne des chfs projets et des contraintes
|
||||
- gestion personnel
|
||||
- gestion comité pilotage
|
||||
- communication interne et externe à la cellule projet
|
||||
- lien avec gestion des programmes
|
||||
- quelques directives ponctuelles
|
||||
- autorisations éventuelles
|
||||
|
||||
5 sous activités :
|
||||
|
||||
- DP1 autoriser initialisation projet
|
||||
- DP2 autoriser projet
|
||||
- DP3 autoriser le plan de séquence
|
||||
- DP4 Directives ponctuelles
|
||||
- DP5 cloture du projet
|
||||
|
||||
**Control de séquence**
|
||||
Travail de surveillance (revu projet quotidienne dans scrum par ex)
|
||||
6 sous process
|
||||
|
||||
- autorisation des lots de travaux
|
||||
- évaluer les lots de travaux
|
||||
- collcter incidences
|
||||
- analyser les incidences
|
||||
- mener actions correctives
|
||||
- réferer les incidents de projet
|
||||
- rceptionner les lots de travaux
|
||||
|
||||
**Livraison des produits**
|
||||
3 sous processus
|
||||
|
||||
- accepter lot travaux
|
||||
- executer lot travaux
|
||||
- livrer un lot de travaux
|
||||
|
||||
**gestion fin de séquence**
|
||||
objectif : faciliter prise de décision pour les séquences
|
||||
=> est c qu'on continue ou on s'arrete ?
|
||||
toujours une phase de go/nogo à la fin, avant d'en entamer une autre
|
||||
6 étpaes
|
||||
|
||||
- ??
|
||||
- mettre à jour plan projet
|
||||
- mettr à jour plan d'affaire
|
||||
- mettr à jour recueil des risques
|
||||
- rapporter (valider) la fin de séquence
|
||||
- produire un rapport d'exception 'celui ci sera transmis au niveau du comité d epilotage qui décidera de quoi fair)
|
||||
|
||||
**cloture du projet**
|
||||
il faut cloturer en s'assurant que celui qui va prnedre en charge en prod a tout ce qu'il faut.
|
||||
il peut y avoir clotures prématurées : mal passé, on fait un no go et on ot prématurément.
|
||||
=> dans ce cas process, on récolute toutes infos et on fait u rapport pour expliquer pourquoi
|
||||
on vérifie que le client a tout ce qu'il veut
|
||||
aussi que on a lo'bligation de moyen (ceux qui vont reprendre projet ont-il toutes ressources pour gérer correctement)
|
||||
faire des recommandation (commenceez pas projet au mois de mai)
|
||||
trallaa lilalouuuuuu
|
||||
|
||||
**planification**
|
||||
qui fait quoi, planification ds équipes, points de difficulté....
|
||||
la gestion de proj st efficace ssi on peut controler la planification
|
||||
128
Cours Conduite projet/Cours 5.md
Normal file
128
Cours Conduite projet/Cours 5.md
Normal file
|
|
@ -0,0 +1,128 @@
|
|||
Cours 5
|
||||
========================
|
||||
|
||||
|
||||
## Gestion des risques
|
||||
|
||||
Le principe est de vérifier que le produit machin les risqus toussa et détecter les malfaçons et de valider et approuver le produit si on est dnas le cas d'une livriason
|
||||
Il y a donc des avantages a avoir un maitre qualité, mais ça a aussi des inconvéients genre les coûts. La revu qualité donne une vraie mesure sur l'avancement du projet et de mettre de la confiance.
|
||||
La cellule qualité permet aussi de s'assurer qu'on va toujours s'améliorer. On implique sérieusmeent la team projet.
|
||||
|
||||
## Gestion des configurations
|
||||
|
||||
C'est le sixième composant. aucune idée de composants de quoi. Ni de qui sont les 5 autres.
|
||||
il parle de ITIL et Prince2 (Lu ?)
|
||||
C'est gérer le versionning du produit.
|
||||
|
||||
|
||||
## Gestion du changement
|
||||
|
||||
On a définir un cadre et en fonction de ce cadre définir gestion du changement adapté pour intégrer ce qu'on a à intégrer en fonctionnalités.
|
||||
|
||||
|
||||
Pour **Prince2** il y a 3 type d'incidents : (oups pu écouté)
|
||||
|
||||
quand on a des problèms enre techniques pas prévus, on utilise le budgt de contingence, prévu par le chef de projet en cas d'iprévus.
|
||||
|
||||
Dans la gestion des problème y a 6 étape
|
||||
|
||||
- détecter
|
||||
- catégoriser
|
||||
- analyser
|
||||
- enquéter sources pour empécher reproduction
|
||||
- documenter (se)
|
||||
- mettre à jour recueil incidents et clui des risques
|
||||
|
||||
on voit avec chef de projet, comité de pilotage et eventuellement d'uatres gus lis au problème => quasiment pareil qu'ITIL
|
||||
|
||||
connaitre impact sur équipe, sur planning (ça prend du temps) possibilité de faire un rollback, est ce que ça a impact sur :
|
||||
|
||||
- projet
|
||||
- gestion des risques
|
||||
|
||||
# Sans titre
|
||||
|
||||
voir schéma sur cours
|
||||
|
||||
|
||||
|
||||
**Elaboration du projet :**
|
||||
|
||||
- nommer un responsable proj
|
||||
- constituer une ou plusieurs équipes construction
|
||||
- nommer équipe de gestion proj
|
||||
- préparer un exposé du projer
|
||||
- définir une approche projet
|
||||
- préparer l'étape d'initialisation
|
||||
|
||||
|
||||
**Initialisation du projet :**
|
||||
- objectif finaliser contrat entre glkjs et posifdlkgj
|
||||
6 sous étapes :
|
||||
- planifier la qualité
|
||||
- mise en place des dossiers du projet
|
||||
- assembler les documents d'initialisation du projet
|
||||
|
||||
**Diriger un projet (DP 1 à 5)**
|
||||
objectifs :
|
||||
gérer ls sous
|
||||
gestion quotidienne des chfs projets et des contraintes
|
||||
- gestion personnel
|
||||
- gestion comité pilotage
|
||||
- communication interne et externe à la cellule projet
|
||||
- lien avec gestion des programmes
|
||||
- quelques directives ponctuelles
|
||||
- autorisations éventuelles
|
||||
|
||||
5 sous activités :
|
||||
|
||||
- DP1 autoriser initialisation projet
|
||||
- DP2 autoriser projet
|
||||
- DP3 autoriser le plan de séquence
|
||||
- DP4 Directives ponctuelles
|
||||
- DP5 cloture du projet
|
||||
|
||||
**Control de séquence**
|
||||
Travail de surveillance (revu projet quotidienne dans scrum par ex)
|
||||
6 sous process
|
||||
|
||||
- autorisation des lots de travaux
|
||||
- évaluer les lots de travaux
|
||||
- collcter incidences
|
||||
- analyser les incidences
|
||||
- mener actions correctives
|
||||
- réferer les incidents de projet
|
||||
- rceptionner les lots de travaux
|
||||
|
||||
**Livraison des produits**
|
||||
3 sous processus
|
||||
|
||||
- accepter lot travaux
|
||||
- executer lot travaux
|
||||
- livrer un lot de travaux
|
||||
|
||||
**gestion fin de séquence**
|
||||
objectif : faciliter prise de décision pour les séquences
|
||||
=> est c qu'on continue ou on s'arrete ?
|
||||
toujours une phase de go/nogo à la fin, avant d'en entamer une autre
|
||||
6 étpaes
|
||||
|
||||
- ??
|
||||
- mettre à jour plan projet
|
||||
- mettr à jour plan d'affaire
|
||||
- mettr à jour recueil des risques
|
||||
- rapporter (valider) la fin de séquence
|
||||
- produire un rapport d'exception 'celui ci sera transmis au niveau du comité d epilotage qui décidera de quoi fair)
|
||||
|
||||
**cloture du projet**
|
||||
il faut cloturer en s'assurant que celui qui va prnedre en charge en prod a tout ce qu'il faut.
|
||||
il peut y avoir clotures prématurées : mal passé, on fait un no go et on ot prématurément.
|
||||
=> dans ce cas process, on récolute toutes infos et on fait u rapport pour expliquer pourquoi
|
||||
on vérifie que le client a tout ce qu'il veut
|
||||
aussi que on a lo'bligation de moyen (ceux qui vont reprendre projet ont-il toutes ressources pour gérer correctement)
|
||||
faire des recommandation (commenceez pas projet au mois de mai)
|
||||
trallaa lilalouuuuuu
|
||||
|
||||
**planification**
|
||||
qui fait quoi, planification ds équipes, points de difficulté....
|
||||
la gestion de proj st efficace ssi on peut controler la planification
|
||||
168
Cours Cryptographie/Cours 1.md
Normal file
168
Cours Cryptographie/Cours 1.md
Normal file
|
|
@ -0,0 +1,168 @@
|
|||
Cours 1
|
||||
========================
|
||||
|
||||
Deux premiers cours : histoire de la crypto
|
||||
Calculatrice : on verra. Si oui, le mieux c'est la TI89
|
||||
Exam : environ 2h, en amphi. 3 exercices :
|
||||
- 1 sur théorème des restes chinois >> là pour attraper un max de points / 4pts
|
||||
- 1 sur questions d'histoire / 4pts
|
||||
- Exercice de cryptage sur un système qu'on a jamais vu ensemble // 12pts
|
||||
|
||||
On ne deviendra pas des experts en crypto juste avec ce module.
|
||||
=> Vision globale
|
||||
|
||||
RSA : cassabl facilemeent, on a just epas la puissance enciore. On rallonge donc régulièrement la clé
|
||||
|
||||
# Lexique
|
||||
|
||||
Cryptologie : science des documents secrets
|
||||
|
||||
cryptanalyse : art et science de décrypter messages secrets
|
||||
|
||||
chiffrement : processus de transformation d'un message en clair de façon à le rendre incomprehensible par toute personne non autorisée
|
||||
|
||||
cryptogramme : résultat du processus de chiffrement
|
||||
|
||||
déchiffrement : processus de reconstruction par personnes autorisées
|
||||
|
||||
décryptage : processus de reconstruction par perosnne non autorisée
|
||||
|
||||
clef de déchiffrement : tout algorithme qui permet de chiffr ou déchiffrer un message
|
||||
|
||||
sténographie : dissimulation d'un message dans un ensemble de données d'apparence anodine
|
||||
|
||||
## Chronologie
|
||||
|
||||
**Polype** - César - **Al Kindi** (900/1000) - **Vigenère**
|
||||
|
||||
Globalement : antiquité / orient / renaissance
|
||||
|
||||
Grandes étapes :
|
||||
Préhistoire
|
||||
Antiquité
|
||||
Moyen-Age (ça explose au Moyen Orient, en chine et en Inde pendant ce temps)
|
||||
1492 (Christophe Colomb)
|
||||
Renaissance
|
||||
1789
|
||||
Temps modernes
|
||||
1914
|
||||
Contemporaine
|
||||
|
||||
Il est exigant sur la chronologie, attention ! On doit être capable de faire une demi pag sur chaque gars à la fin.
|
||||
|
||||
## Différentes stratégies
|
||||
|
||||
Cacher - coder - crypter
|
||||
|
||||
### Cacher
|
||||
|
||||
#### Steganographie
|
||||
cacher le message dans un support qui semble anodin.
|
||||
|
||||
- noyer le message dans un autre
|
||||
- écrire sur crâne et attendre que cheveux repousse
|
||||
- écrire sur tablette en bois et recouvrir de cire pour faire croire à tablette vierge
|
||||
- message sur fine soie enrobée dans cire, puis messager avale boule
|
||||
- message dans un oeuf dur : de l'alun avec bcp de vinaigre pénètre la surface et s'inscrit sur le blanc
|
||||
- petits trous sous les lettres d'un texte, qui si on en prend que ces lettres donnent le message
|
||||
- micropoints : les allemands utilisaient ça dans la seconde guerre mondiale : taille d'un point de ponctuation, qu'il fuat agrandir pour lire le message dedans.
|
||||
|
||||
Le micropoint est très utilisé aujourd'hui : billets de banque, chèques...
|
||||
|
||||
Intégration dans les gènes ! Création d'une clé d'encryption en créant un allphabet à partir séquenc de 3 lettres.
|
||||
On part un peu loin avec modification génétique
|
||||
|
||||
Eugénisme : exemple Norvège qui veut faire race supérieure : 1860 à 1940 d'abord via des allocs pour grands blonds yeux bleux qui font enfants et taxe spour autres, puis interdiciton couples pas gbyb de faire gosses, puis stériilisations femmes qui ont pas gènes gbyb.
|
||||
|
||||
#### Encres sympathiques
|
||||
|
||||
Rabelais : médecin habitant de Lyon, officiait à l'hotel Dieu. Romans très bons : Pantagruel.
|
||||
Wikileaks de l'époque : il balançait infos sensées rester secrètes.
|
||||
Dans pantagruel il expliques toutes techniques pour encres sympatiques :
|
||||
|
||||
- sel ammoniauqe dans l'eau : près du feu
|
||||
- suc de tithymalle : dans l'eau
|
||||
- jus oignon blanc : montrer à la chandelle
|
||||
- extrait figuier : huile de noix
|
||||
- ...
|
||||
|
||||
#### Grille de Cardan
|
||||
|
||||
Faire fenetres dans un cache et placer cache sur un texte pour faire apparaitre message à travers fenetres
|
||||
|
||||
#### Ave Maria de Tritheme
|
||||
|
||||
Chaque bout de phrase correspond à une lettre, et on construit un texte à partir de ces phrases.
|
||||
|
||||
#### L'alphabet bilitère de Francis Bacon
|
||||
|
||||
joue avec iprimrie : normal ou en italique. si normal : A, si italique : B. Groupe de 5 lettres, et selon agencement donne un caractère (genre AAAAA = A)
|
||||
Problème : longueur et différence de typo dure à voir
|
||||
|
||||
2volution vers le trilitère : normal, italique et plus grosse.
|
||||
problèm : déjà dur à voir à 2, hardore avec 3.
|
||||
Jamais utilisé vraiment
|
||||
|
||||
#### Semagrammes
|
||||
|
||||
utilisation des ntes de musique : du do au la, pour blanche, noire, croche... : 39 possibilités = alphabet, 10 chiffres, ponctuation
|
||||
dans un dessin, mettre éléments codés (herbes longues ou courtes, mouches dont emplacement correspond à lettre alphabet...)
|
||||
|
||||
#### Lettres codés de Sand et de Musset
|
||||
|
||||
Lire une ligne sur deux // Acrostiche (pas de lettre, de mot)
|
||||
|
||||
#### Le "soi disant" code secret de la bible
|
||||
|
||||
le gars a collé toutes les lettres de la bible et fait des sauts entre les lettre pour capter des "messages secret"
|
||||
Théorème de Borel : avc un grand nombre de lettrs, on peut faire plein de mots.
|
||||
|
||||
### Coder
|
||||
|
||||
#### Le code de Mary Stuart
|
||||
|
||||
elle pensait qu son code était solide mais elle s'est fait capter. elle montait complot pour renverser elisabeth reine. les cryptanalystes ont réussi à décoder et inséraient des faux Post scriptum dans les lettres pour récupérer infos et démanteler le réseau.
|
||||
|
||||
#### Le code de Popham
|
||||
|
||||
Code avec des drapeaux pour communiquer à distance entre bateaux.
|
||||
Sémaphore : les deux drapeaux avec rouge/jaune en diago
|
||||
|
||||
#### Le morse
|
||||
|
||||
bien connu. Pensé pour que les lettres les plus utilisées soient symboles courts
|
||||
|
||||
#### L'ASCII
|
||||
|
||||
...
|
||||
|
||||
#### Le code Navajo
|
||||
|
||||
Une langue indigène (indienne) très complexe. Ils ont utilisé cette langue (un millier d'utilisateurs au monde tout au plus). Cétait donc codé et si décodé en plus la langue était impossibl à comprendre.
|
||||
difficulté : les mots de la langue sont pas adaptés donc ils trouvent des équivalents. Fallait aussi pas qu'un Navajo trombe aux mains de l'ennemi.
|
||||
|
||||
### Crypter
|
||||
|
||||
#### Approche 01 : Le chiffre de transposition
|
||||
|
||||
On change l'ordre des lettres selon un clé indiquant comment on permute sur un lot de n lettres. (genre 4 lettres qu'on change en 2, 4, 1, 3)
|
||||
Ca a été utilisé par Galilée notamment, pour protéger ses recherches : il avait publié le truc en crypté pour prouver qu'ilétait le premier à avoir trouvé qqch.
|
||||
|
||||
##### Lecture globale
|
||||
|
||||
En lecture globale on peut trouver facielment (ne bloquant la première et la dernière et on change l'ordre lettres dnas mot)
|
||||
|
||||
|
||||
##### Scytale romaine
|
||||
|
||||
bâton sur lequel on enroule ruban et on écrit dessus, puis complète avec autres lettres, il faut ensuit baton du bon diamètre pour déchiffrer
|
||||
|
||||
##### Rail Fence
|
||||
|
||||
Séparation en deux du message en deux niveaux, une lettre dans chaque dans l'ordre.
|
||||
On peut faire en trois niveaux ou plus
|
||||
|
||||
##### La grille tournante
|
||||
|
||||
grille avec cache devant qui lorsqu'on le tourne laisse aparraitre des cases différentes. on écrit message en remplissant la grille à travers cache et en le tournant d'un quart de tour à chaque fois. on a ensuit une grille remplie dont on transmet les lettres. Pour déchiffrer, remontrer la grille et mettre le cache.
|
||||
|
||||
15
Cours Cryptographie/À voir.md
Normal file
15
Cours Cryptographie/À voir.md
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
À voir
|
||||
========================
|
||||
|
||||
## Films
|
||||
|
||||
- Imitation game (parle de Turing)
|
||||
- Bienvenue à GATTACA (tiré d'un livre : le meilleur des mondes / aldous Huxley)
|
||||
- Les messagers du vent (Wind Talkers), parle langage Navajo
|
||||
|
||||
|
||||
## Livres
|
||||
|
||||
- Histoire des codes secrets, Simon Sigh
|
||||
- Le dernier Théorème de Fermat, Simon Sigh
|
||||
- Le grand roman du Big Bang, Simon Sigh
|
||||
173
Cours Droit/Cours 3.md
Normal file
173
Cours Droit/Cours 3.md
Normal file
|
|
@ -0,0 +1,173 @@
|
|||
Cours 3
|
||||
========================
|
||||
## Rappels
|
||||
|
||||
N'est pas libre et éclairé : violence, deule (tromper quelqu'un), l'erreur (de bonne foi et excusable)
|
||||
|
||||
## Date et lieu de formation du contrat
|
||||
|
||||
Permet de situer le délai de garantie, d'échéance du contrat si durée déterminée... c'est donc important.
|
||||
En droit de la consommation, le consommateur peut choisir le juge où assigner la personne.
|
||||
|
||||
|
||||
|
||||
La justice prédictive permet d'anticiper ce qui va se passer si on fait recours à un juge et ainsi mieux déterminer les conséquences d'une action en justice.
|
||||
|
||||
## C - Accord sur l'objet et sur le prix
|
||||
L'objet, c'est la fourniture d'une chose ou la prestation d'un service en contrepartie du paiement du prix. Il est essntiel que le contrat ait un objet. Dans tous les contrats, on aura une clause qui portera la dénomination "objet".
|
||||
Attention, l'objet peut toujours être déterminable même s'il n'est pas forcément déterminé
|
||||
|
||||
Accord sur le prix : il est obligatoire ! Attention toutefois : dans le cadre d'un contrat d'entreprise, les contrats d'entreprises étant des fournitures de services exécutés par des prestataires, le prix n'est pas une condition essentielle pour la conclusion du contrat. Il peut être déterminé par la suite ou il peutêtre convenu que ce prix évoluera (ex : prix indexé sur le cours du matériau, mais l'index doit êtr commun aux deux parties)
|
||||
|
||||
|
||||
# Chapitre 2 : L'exécution du contrat
|
||||
|
||||
## 1 - Suivi de l'exécution
|
||||
|
||||
### A - Évolution
|
||||
|
||||
durant tout l'exécution du cointrat, il y a un devoir de conseil de la part du fournisseur du service et un devoir de collaboration de la part du client.
|
||||
Le devoir de conseil consiste e une mission d'assistance technique lors de la mise en route du logicile ou de l'installation (= service apres-vnte des grosse boites)
|
||||
|
||||
Devoir de collaboration : Le client doit continuer à collaborer avec le fournisseur en se montr ant actif tout au long de la mis en oeuvre du système.
|
||||
|
||||
Création d'un comité de suivi : c'est une véritable structure de conceratation et de contrôle entre les partis. Il est utile de prévoir contractuellement le comité de suivi, stipulant quand il se rtrouve et d qui il est composé
|
||||
|
||||
Maitrise d'oeuvre : dans les projets de grand envergure, on peut croiser le maitre d'oeuvre en plus du comité de suivi. Le MOe informatique est celui qui a en charege la concetpion intelectuelle du projet et sa réalisation globale. Le MOE communiqu directement avec le MOA, qui est celui pour qui l projet est réalisé. Il a n chagre la définition des besoins ?
|
||||
|
||||
### B - Évolution du contrat
|
||||
|
||||
Un contrat se modifie par avenant. On ne cré pas un nouveua contrat, on crée une nouvlle disposition à l'intérieur.
|
||||
Si on veut être précis, on dit que chaque clause est une stipulation.(on dit que la loi dispose et que la justice stipule)
|
||||
|
||||
Le contrat peut prévoir dses "mécanismes d'actualisation". L'indice retnu pour l'ctualisation du prix doit avoir un lien direct avc l'bjet du contrat.
|
||||
|
||||
La chambre syndicale des sociétés d'étude et de conseil qu'on appelle S.YN.T.E.C a machinmachin l'indice les plus retenus :
|
||||
la PSDB et LE PSDC. Et l'INSEE est dnas l lot aussi, j'sais pas pourquoi. Ca permet d'évauer le prix moyen des différentes prestations.
|
||||
|
||||
## 2 - Livraison de la prestation
|
||||
|
||||
La livraison doit être faite dans les délais prévus. Lorsque la livraison est reçue, il faut s'assurer qu'elle soit conforme à ce qui est delandée.
|
||||
Pour les systèmes informatiques, la responsabilité des fournisseurs n'est qu'engagée qu'après l'écoulment d'une période de rodage.
|
||||
|
||||
C'est à l'utilisateur de rapporter la preuve des défauts de conformité. Pour que les défauts soient acceptés ils doivnt être suffisemment importants pour mettre en cause l'exploitation dans son ensemble.
|
||||
|
||||
La délivrance de matériel ou de xx informatique doit toujours s'accompagner des accessoires nécessaires pour l'utilisation normale
|
||||
Si aucun délai de livraison n'est fixé il appartient au juge ~~de boire du foutre~~ de déterminer le délai raisonnable.
|
||||
|
||||
## 3 - Contrôle de la conformité
|
||||
|
||||
L contrôle de la conformit peut être tacite. Après un certain délai, si aucun action n'est engagé on considère que le contrôle de conformité est correct.
|
||||
À l'inverse il peut être express. C'est alors au client de faire part des réserves qu'il aurait pu émttre. Par xemple, on peut récupérer un colis et dire "sous réserve du contrôle de conformité"
|
||||
|
||||
## 4 - Les garanties
|
||||
|
||||
Il existe plusieurs typs de garanties.
|
||||
|
||||
La première dont on n peut pas se défaire :
|
||||
|
||||
### A - La garantie légale des vices cachés
|
||||
|
||||
Le vendeur est tenu de garantir les vices cachés de la chose vendue
|
||||
Les vices cachés se définissent légalement comme étant un défaut qui rendl'usage de la chose imporpre au fonctionnement. ce sont des vices qu'on aurait pas pu connaitre avant l'utilisation du matériel parce qu'ils sont dnas la structure interne du matériel. ces vices les rendent inutilisable ou tellement difficles d'utilisation que s'il les avait connus l'utilisateur ne les aurait pas achetés, ou pas à ce prix-là.
|
||||
Si on a conscience de ces vices, si on les connait, ça entre plus dnas les vices cachés.
|
||||
|
||||
L'action contre les vices cachés doit être intnté ans un délai de deux ans **à compter du jour ou l'acquéreur à eu conscience du vice**
|
||||
|
||||
### B - Vices cachés et logiciels
|
||||
|
||||
Pour procéder le consommatur, la jurisprudence n'accepte pas le bug dans un logiciel, car le bug est "inévitable" dans un logiciel. Impossible donc de faire marcher le vice caché si on rencontre un bug dans un logiciel, **sauf si il rend le logiciel inutilisable**
|
||||
|
||||
### C - Vices cachés et non-conformité
|
||||
|
||||
non-conformité = le produit ne correspond pas à nos attentes.
|
||||
Ne marche pas pour les denrées consommables
|
||||
|
||||
### D - Clauses limitatives de garantie
|
||||
|
||||
Il est tout à fait possible de prévoir de sclauses limitatives de garantie, à la seule condition que l'on aie pas connaissance du défaut.
|
||||
|
||||
### E - Autres garanties
|
||||
|
||||
Il en existe bcp
|
||||
|
||||
Eviction : garantir qu personne ne va intervenir pour pourrir votre marchandise.
|
||||
garantie de conformité : automatique, s'applique sur tous ls biens de consommation. Elle est de deux ans. Elle couvre uniquement l'utilisation normale d'un appareil.
|
||||
La garantie contractuelle peut être totalement facultative, se juxtapos à la grantie légale. Ex : extension de garantie. A la longueur temporelle que l vendeur souhaite et peut concerner plus ou moins de choses.
|
||||
|
||||
## 5 - La responsabilité
|
||||
|
||||
### A - L'étendue des engagements
|
||||
|
||||
Il s'agit de savoir qui est responsable, à quel moment et en fonction de quoi ?
|
||||
Ça dépend de deux types d'obligations :
|
||||
- moyen : tout mettre en oeuvre pour (ex: docteur)
|
||||
- résultat : on doit obtenir un résultat
|
||||
selon le type de l'obligatin, l'étendue de la responsabilité va varier
|
||||
|
||||
En informatique, on doit tout mettre en oeuvre pour respecter ses obligation. Y a obligation de moyen quad il y a aléa. Ex : conseil. Il va appartenir au client de rapporter la preuve de la faute de ce dernier en démontrant qu'il n'a pas tout mis en oeuvre pour l'aider.
|
||||
Obligation de résultat, c'est dès lors qu'il y a un résultat précis. ex : vente de matériel informatique, ou bien contrats clefs en main. Il suffit pour le client de montrer le défaut de résultat.
|
||||
|
||||
### B - Les conditions de mise en oeuvre
|
||||
|
||||
Pour engager la responsabilité contractuelle du fournisseur, c'est au client de rapporter la preuve de la faute (le "dommage"). Le dommage doit être direct, certain et licite. Il doit y avoir un lien de causalité prouvé entre le dommage et la faute. seuls les dommages prévisibles sont réparables.
|
||||
en cas de force majeure, la jurisprudence accepte que le vendeur soit considéré comme irresponsable. Ex : livraison d'un bien à un date donnée (résultat). Bien pas livré > responsable, remboursement. Cas de foirce majeure : neige.
|
||||
cas de force majeure : imprévisible et irrésistible.
|
||||
|
||||
### c - Clause pénale
|
||||
|
||||
L'idée est déviter d'avoir recours au juge. C'est mettre en place un mécanisme de sanctions (pécuniaires) en cas d'inexécutions d'une des obligations contracutelles. Et des sanctions automatiques. Ex : livré en 30 min ou remboursé.
|
||||
Ces clauses n'ont pas beosin d'un jug, il suffit de contacter le contractant et de ls revendiquer
|
||||
|
||||
# CH3 - fin du contrat
|
||||
|
||||
La fin du contrat arrive de plusieurs facons :
|
||||
|
||||
## 1 - Inexécution du contrat
|
||||
|
||||
C'est une clause de fin de contrat
|
||||
raison principale :
|
||||
|
||||
### A - Non paiement du prix
|
||||
|
||||
si on paye pas, le contrat prend immédiatmenet fin. Pareil si on paye et le produit est pas fourni.
|
||||
|
||||
Si paiement en succesif, l'inexécution des paiements successifs peut etre un motif de paralysie (inexécution du contrat). Ex : maintenance sur plueiurs mois
|
||||
|
||||
### B - Règlement amiable des litiges
|
||||
|
||||
Suscitent de nombreux litiges, réglés en général devant juge. Mais autant éviter
|
||||
|
||||
#### a - Conciliation entre les parties
|
||||
|
||||
Il peut y avoir dans le contrat une clause qui prévoit les modalités pour parvenir à un accord si il y a un problème dans l'exécution du contrat.
|
||||
|
||||
#### b - concilitation par un tiers
|
||||
|
||||
on peut prévoir dans le contrat d'avoir recours à une tierce personne. Elle peut être définie précisément dès le contrat ou prévue par la suite.
|
||||
|
||||
### C - Résolution du contrat
|
||||
|
||||
Il existe dux mots pour parler de la fin d'un contrat :
|
||||
résolution : rétroactivement (on considère que le contrat n'a jamais existé, on revient sur ce qui était > remboursement)
|
||||
résilitation : pour l'avenir
|
||||
|
||||
La résolution sera prononcée par un juge, suite à une sanction
|
||||
Dans l cadre d'une résilitation ou résolution, mais plus souvent résilitation, le client a l'obligation de resistuer l'ensemble ds logiciels ou du matériel qui lui a été donné (loué) dans le cadre du contrat. Dans le cadre d'un logiciel loué, l'entrprise a l'obligation de restituer toutes les coopies du logiciel en sa possession, et de certifier qu'ell a détruit ou rendu tous les éléments de logiciel en sa possession.
|
||||
|
||||
#### Dommages et intérêts
|
||||
|
||||
Il s'agit de dommages qui peuvent être donnés compensés. Une erreur ou une faut du à l'exécution ud contrat.
|
||||
|
||||
#### clause résolutoire
|
||||
|
||||
elle permet demettre fin au contrat sans passer par le juge et de mettre fin au contrat de façon rétroactive. Attention les gens de loi sont très attentifs à la manière dont cette clause est rédigée car c'est important. Pour être valide, il faut que les deux puisses activer cette clause, elle ne peut pas être au bénéfice d'une seule, et il faut qu'il y ait une mise en demeure express (lettre avec accusé de réception).
|
||||
|
||||
## 2 - Arrivée à terme du contrat
|
||||
|
||||
Une des cuase d'extinction du contrat. Même dans le cadre d'un CDI, il est interdit de prendre des engagements à vi (illimités). À tout moment, il y a possiblité de rompre son contrat. Même les contrats a priori faits à vie sont des contratds qu'on peut rompre à tout moment.
|
||||
|
||||
## 3 - Sortie anticipée du contrat
|
||||
|
||||
On peut sortirde manièr anticipée. Il faut respecter période de préavis. si on la respecte pas, faut payer.
|
||||
|
||||
4
Cours Droit/Note 2018-04-16T11.15.33.md
Normal file
4
Cours Droit/Note 2018-04-16T11.15.33.md
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
Note 2018-04-16T11.15.33
|
||||
========================
|
||||
|
||||
R
|
||||
59
Cours Droit/RGPD.md
Normal file
59
Cours Droit/RGPD.md
Normal file
|
|
@ -0,0 +1,59 @@
|
|||
RGPD
|
||||
========================
|
||||
|
||||
Règlement Europén en 6 étapes
|
||||
|
||||
Source du droit : Droit de l'UE
|
||||
|
||||
La CNIL vérifie que le règlement europén est bien appliqué dnas le dorit interne.
|
||||
En droit interne on a un protocole qui date de la loi informatique et libertés de 1978.
|
||||
|
||||
Pas un changement de ouf car on avait déja la plupart des règles en France.
|
||||
CNIL propose 6 étapes :
|
||||
**1 - Désignation d'un pilote**
|
||||
Rôle du pilote ? c'est le délégué à la protection des données
|
||||
il est obligatoire dans deux cas :
|
||||
- si on est un organisme public
|
||||
- si votre entreprise vous amène à réaliser un suivi régulier et systématique de personnes à grande échelle ou si vous traitez des données sensibles ou encore si c sont des données relatives à la condamnation pénale et à des infractions
|
||||
|
||||
Même si l'entrprise n'est pas obligée, il est fortement recommandé d'en désigner un.
|
||||
|
||||
Rôle :
|
||||
- il est tenu d'informer et de conseiller tous les responsables de traitement des données
|
||||
- lien entre autorité de controle (cnil) et l'entreprise.
|
||||
|
||||
**2 - Cartographier le traitement de données personnelles**
|
||||
|
||||
- Idntifier ce qui est données perso et ce qui ne l'est pas
|
||||
- savoir pour chaque donnée, pourquoi on l'a
|
||||
- identifier les flux de ces données
|
||||
|
||||
pour chaque type de donnée perso, il faut se poser toute une série de qustions :
|
||||
- qui gère la donnée ?
|
||||
- quelle catégorie de donnée il s'agit ?
|
||||
- pour quoi ?
|
||||
- où stocke-t-on la donnée (y compris servur svg)
|
||||
- jusqu'à quand ? chaque catégorie a règle de conservation spécifique
|
||||
- comment ? quelles sont les mesures de sécurité qu'on va mettr en oeuvre ?
|
||||
|
||||
**3 - Prioriser les actions**
|
||||
|
||||
plus on a de données, plus c'est lourd. Il faut d'abord se concentrr sur le plus important : qui gère, où et avec quelle sécurité ?
|
||||
|
||||
**4 - Gérr les risques**
|
||||
important d'anticiper la gestion des risques ! Permet d'orienter sur les premières missions à mener. faire étude d'impact de la protection des DP
|
||||
|
||||
**5 - Organiser un processus interne**
|
||||
|
||||
Arrive rà mettre en place protocole dna entrprise qui pourra répondr eà toutes questions de sécurité utile. (ex : commencer par campagne de sensibilisation). Le protocole doit être adapté à l'entrprises et aux données que l'on gère.
|
||||
en cas de violation des données, on a 72h pour prévnir les autorités compétentes (cnil) et les personnes concernées sur la violation des données qui a eu lieu
|
||||
|
||||
** 6 - Crér un document de la conformité**
|
||||
|
||||
il s'agit de réunir dans un même dossier l'nsemble des informations qu'on a pu mettre en place concernant l'entreprise.
|
||||
- Doit comporter obligatoirement la documentation sur le traitement des données personnelles. - - Doit aussi comporter la doc relative à l'information des personnes
|
||||
- et aussi les contrats qui définissent les rôles et la responsabilité des acteurs. Qui est/sont les sous traitants par exempl.
|
||||
|
||||
Plus gros points :
|
||||
- sensibilisation des employés
|
||||
- machins mis en plac epour assuer la protection.
|
||||
78
Cours Génie Logiciel/Architecture monolithique.md
Normal file
78
Cours Génie Logiciel/Architecture monolithique.md
Normal file
|
|
@ -0,0 +1,78 @@
|
|||
Architecture monolithique
|
||||
==============
|
||||
|
||||
*19/04/18*
|
||||
|
||||
## Principes du monolithique
|
||||
|
||||
"qui est fait d'un seul bloc" => code dans un seul fichier.
|
||||
créé à partir des premiers langages pour comminuqer avec machines (le B, le C). On scriptait tout dans un seul fichier.
|
||||
Ca a perduré avec le temps.
|
||||
=> ça a donné crise du logiciel par la suite
|
||||
|
||||
## Application monolithique
|
||||
|
||||
Ne fonctionne qu'avc une seule technologie parce que c'est conçu pour aller d'un point A à un point B
|
||||
Conçu pour remplir un but de la façon la plus simple possible.
|
||||
Ça bloque donc au niveau technologique => restreint dans techno utilisée de base.
|
||||
Le logiciel a une seule techno et donc c'est ce logiciel qui fait tout, quel que soit le niveua de l'action.
|
||||
Difficulté dans changement : on doit tout reprendre pour la moindre modification, il fuadrait tout réécrire, sinon ça risque de pas s'mboiter avec le reste. De plus en plus compliqué de modifier quand logiciel grossit.
|
||||
Excellentes possibilités doptimisation du code par contre : on doit répondre à un besoin simple et on réfléchi à l'optimisation de son exécution.
|
||||
|
||||
### Déploiement
|
||||
|
||||
il est assez simple, car on a un serveur, un processus.
|
||||
encore une fois ça pousse à l'optimisation : bons temps de réponse, exécution rapide.
|
||||
|
||||
### Gestion de projet
|
||||
|
||||
Methodo datant des années 70/80
|
||||
Pas de méthodes agiles, plutôt en cascade couplé avec cycle en V.
|
||||
Agile serait impossible à mettre en place. On part du principe qu'on a un CdC et qu'on doit tout mettre en place. Pas de modularité, on a un seul bloc !
|
||||
|
||||
Méthode en cascade héritée du BTP :
|
||||
|
||||
* recueil des besoins
|
||||
* analyse détaillée
|
||||
* conception détaillée
|
||||
* Développement
|
||||
* Test, recettes
|
||||
* Livraison
|
||||
|
||||
Face à quelques difficultés, on améliore la cascade pour partir sur modèle en V !
|
||||
Il permet en effet plus facilement de revenir sur l'étape précédente. Ça apporte plus de flexibilité
|
||||
|
||||
## Avantages et inconvénients
|
||||
|
||||
Miam :
|
||||
|
||||
* Plutôt avec des lanages bas niveau => grnade maitrise logicielle et matérielle, logiciels très optimisés. On fait des géants très performants avec ça
|
||||
* L'application va faire tous les traitements de A à Z => facile à conceptualiser, à concevoir. Moins de complexité dnas la gestion et la construction que microservice.
|
||||
* Facilité de déploiement !
|
||||
|
||||
Berk :
|
||||
|
||||
* Fort couplage des modules => application difficile à revoir et à modifier sans avoir à tout revoir dans l'application
|
||||
* le code devient vite difficile à comprendre => vriament dur à faire évoluer, en plus c'est prendre des risques si on mélange les équipes qui travaillent dessus. Le code devient n'importe quoi
|
||||
|
||||
|
||||
## Monolithiques VS microservices
|
||||
|
||||
Joli tableau dans le prezi
|
||||
|
||||
## Conclusion
|
||||
|
||||
la monolithique est encore très utilisée aujourd'hui, bien que microservices soient préconisés
|
||||
La majorité des logiciels aujourd'hui sur un PC par exemple est en monolithique.
|
||||
Les microservices sont surtout présents dnas web
|
||||
Entreprises s'y mettent mais logique et trucs présents sont encor en monolithique.
|
||||
|
||||
On est vraiment bloqués sur une techno
|
||||
Forte possibilité d'amélioration du code
|
||||
Gestion de projet en cascade et V
|
||||
un seul truc qui fait tout
|
||||
|
||||
|
||||
## Bouiche
|
||||
|
||||
J'ai pas écouté, le smiley Gui m'a déconcentré
|
||||
48
Cours Génie Logiciel/COBIT.md
Normal file
48
Cours Génie Logiciel/COBIT.md
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
COBIT
|
||||
========================
|
||||
*20/04/18*
|
||||
|
||||
## Introduction
|
||||
|
||||
**C**ontrol O**b**jectives for **I**nformation and related **T**echnology
|
||||
|
||||
Fait en 1994, publié en 1996
|
||||
|
||||
La plus utilisée = version 4.1
|
||||
|
||||
## Principe
|
||||
|
||||
Sert à optimiser trucs informatiques :
|
||||
|
||||
* organiser DSI
|
||||
* auditer DSI
|
||||
* mesurer sa performance et sa maturité
|
||||
* ...
|
||||
|
||||
Se presente sous tableau avec grille (consulté - supervise... comme dans EBIOS (?))
|
||||
Y a plusieurs vues, hein, une tétrachié même
|
||||
|
||||
|
||||
## Version 4.1
|
||||
|
||||
BAsé sur un pentagone qui fournit des processus pour lier différents "trucs" :
|
||||
|
||||
* alignement stratégique
|
||||
* value delivery : valeur des métiers
|
||||
* managements des risques : risques liés à l'informatique & que info put diminuer
|
||||
* resources management: bonne gstion du temps et budget et personnes
|
||||
* performance mesurement : permet de se mesurer dans efficacité
|
||||
|
||||
## Version 5
|
||||
|
||||
Version 4 juste basée sur gouvernance, là ou le 5 est sur management et gouvernance : englobe entreprise entière
|
||||
|
||||
Version 5 a 5 principes aussi. Au lieu de se baser sur un seul référentiel, ils créent un "méta réfentiel" qui en englobe plusieurs. => toutes les bonne spratiques d'une entreprise.
|
||||
|
||||
## Bouiche
|
||||
|
||||
TOGAF 9 : savoir qu'il existe et ce qu'iul fait c'est bof
|
||||
Prince2 : plus important
|
||||
ITIL : aussi
|
||||
PMBOK : c'est un plus sur un CV - vraiment à connaitre
|
||||
COSO
|
||||
45
Cours Génie Logiciel/Cours général.md
Normal file
45
Cours Génie Logiciel/Cours général.md
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
Cours général
|
||||
========================
|
||||
|
||||
## Cycles du dévloppement informatique
|
||||
|
||||
### Les différents types d'essai
|
||||
|
||||
Gérer tests et erreurs
|
||||
|
||||
### Les documents livrés
|
||||
|
||||
|
||||
### Les risques
|
||||
|
||||
* humains
|
||||
* technologiques
|
||||
|
||||
Sont à prévoir en tant que manager, leur probabilité, leur type, et la solution préconisée
|
||||
|
||||
|
||||
### La maintenance
|
||||
|
||||
* Corriger ls bugs, erreurs résiduelles = maintenance corrective
|
||||
* maintenance adaptative
|
||||
* Maintenance évolutive
|
||||
|
||||
## Les modèles de développement
|
||||
|
||||
* cascade
|
||||
* cycle en V
|
||||
* spirale : si on a pas de résultats en 3 cycles, y a un souci
|
||||
* semi itératif : début en chute d'eau ensuite, on peut revenir en arrière
|
||||
* itératif
|
||||
|
||||
## Méthodes agiles
|
||||
|
||||
Valorise l'humain, le travail, implique le client.
|
||||
|
||||
## Cycle de vie d'un projet
|
||||
|
||||
|
||||
## Random
|
||||
|
||||
Il faut écouter les membres de son équipe. u_u
|
||||
si on les implique, ils apprennent.
|
||||
42
Cours Génie Logiciel/Design pattern.md
Normal file
42
Cours Génie Logiciel/Design pattern.md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
Design pattern
|
||||
========================
|
||||
|
||||
# Intro
|
||||
|
||||
Ca aide les dev à bien oprganiser leur code
|
||||
|
||||
# Catégories
|
||||
|
||||
Création : anièr de crér un objet ou un ensemble d'objet
|
||||
Comportement : manière d'interprétation du code et des objets
|
||||
Structure :
|
||||
|
||||
# Avantages
|
||||
|
||||
modularité : modules bien précis, on sait ou chercher
|
||||
cohésion
|
||||
couplage : modules s'intancient ls uns dnas les autres pour etre réutilisés
|
||||
rutilisablilité : bibliothèques, frameworks utiles à d'autres
|
||||
|
||||
# incovénient
|
||||
|
||||
complexité : c'est dur à apprendre (long)
|
||||
effrot abstraction/synthèse : gros travail préalable et faut le prendr en main
|
||||
|
||||
# Les frameworks qui utilisent
|
||||
|
||||
.net en implémentation
|
||||
JavaServer Faces
|
||||
MVC
|
||||
spring
|
||||
|
||||
# Conclusion
|
||||
|
||||
c'est quand même utile
|
||||
|
||||
# Bouiche
|
||||
|
||||
C'est orienté objet, langage objet.
|
||||
Il a pas assez parlé des API
|
||||
API : bibliothèque qui pourront être réutilisés dans d'autres codes
|
||||
il est ilportant en design pattern de réutiliser ce squi a déjà été fait
|
||||
6
Cours Génie Logiciel/Exam.md
Normal file
6
Cours Génie Logiciel/Exam.md
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
Exam
|
||||
========================
|
||||
|
||||
5/10 questions par exposé
|
||||
|
||||
pas de documents autorisés
|
||||
55
Cours Génie Logiciel/Exposé MicroServices & Webservices.md
Normal file
55
Cours Génie Logiciel/Exposé MicroServices & Webservices.md
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
Exposé MicroServices & Webservices
|
||||
========================
|
||||
|
||||
Alexandre et Morgan
|
||||
|
||||
## Présentation
|
||||
|
||||
C'est quoi ? > Méthod de devloppement logiciel basé sur conception de plusieurs tout petits services indépendants et autonomes.
|
||||
Opposé au monolithique.
|
||||
Système minimaliste, souple : si on intervient ou conçoit un service, on a en soit pas à se soucier des autres, ni de redéployer l'application en entier.
|
||||
|
||||
4 points principaux :** componentization**
|
||||
|
||||
1 > Cohérence et logique et logique système : KISS, ou you has one job
|
||||
|
||||
2 > spécificité des fonctionnalités : ils sont tous indépendants l suns des uns, is un tombe les autres non.
|
||||
|
||||
3 > Autonomie des services
|
||||
|
||||
4 >
|
||||
|
||||
Opposition monolithique et microservices : monolithique = une grosse BDD partagée
|
||||
micros : plein de petites, parfois partagées pour quelques microservices
|
||||
|
||||
## Communication des ms entre eux
|
||||
|
||||
Deux grosses manières : REST et bus de message
|
||||
|
||||
### REST : par http(s)
|
||||
#### Avantage :
|
||||
tous les services se comprennent (grand interopérabilité entre systèmes et applications)
|
||||
assez simple à mettre en place
|
||||
|
||||
#### Inconvénient :
|
||||
débordment de messages http(s), chacun envoyant les siens, surcharge réseau
|
||||
|
||||
### Bus de messages
|
||||
un serveur réceptionne tous les messages et le tranmet aux autres services
|
||||
il ne les traite pas ! renvoie juste, plutot rapide
|
||||
|
||||
#### Inconvénient :
|
||||
fragile, si le serveur tombe c'est la merde.
|
||||
|
||||
|
||||
|
||||
Les ms impliquent de repenser l'équipe de dev, qui s'oriente autour des fonctionnalités et non des compétence smétier. on a aussi des petites équipes et une orientation servis = un produit
|
||||
|
||||
## Avantages et inconvénients
|
||||
|
||||
### avantages
|
||||
|
||||
dévelopements et déploiement indépendant : Petites équipes, différents langages pour chaque service.
|
||||
|
||||
## Démonstration technique
|
||||
|
||||
55
Cours Génie Logiciel/ITIL.md
Normal file
55
Cours Génie Logiciel/ITIL.md
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
ITIL
|
||||
========================
|
||||
règle des problèmes récurrent en POO
|
||||
|
||||
objectif : améliorer efficacité
|
||||
|
||||
# Histoir
|
||||
|
||||
années 80 > datacenter se décentraliser et architectures distribuées. Gouvernement royaue uni
|
||||
|
||||
s'appui sur 5 publicatiosn essentielles
|
||||
- Service Strategy
|
||||
- Service Design
|
||||
- Service Transition
|
||||
- Service Operation
|
||||
- Continual service
|
||||
|
||||
Je suis crevé j'bandonne
|
||||
|
||||
|
||||
## Gestion infrastructure
|
||||
|
||||
les infra informatique sont gérées par tout ce qui est nécssaire pour fournir service
|
||||
|
||||
## les experts de l'infra en ITIL
|
||||
|
||||
y aplein d'experts
|
||||
|
||||
# Gestion des accès
|
||||
|
||||
processus d'application de politique de sécu.
|
||||
|
||||
# Service desk
|
||||
poitn contact unique entre client et service informatiuqe 'suivi incident ou probleme)= tout contact passe par là
|
||||
en général divisé en niveuax 1/2/3 > service alors dit verticaux
|
||||
on peut aussi les avoir en horizontaux : 1 répond et gère au max sinon réoriente vers un spécialiste
|
||||
jamais un usr contacte un niveua supérieur en direc tou un presta externe
|
||||
|
||||
# Gestion des évènements
|
||||
|
||||
y faut faire roter vers les gens compétent
|
||||
|
||||
# Gestion des problèmes
|
||||
|
||||
# Conclusion
|
||||
|
||||
J'ai rien compris
|
||||
|
||||
# Bouiche
|
||||
|
||||
dit qu'il faut retenir en ITIL que le plus important c'est qu'il faut retenir de ses erreurs
|
||||
On enregistre tout, on loggue tout
|
||||
Il y a plusiuers versions d'ITIL
|
||||
ITIL c'est du bon sns, c'est une organisation de service.
|
||||
Ça apprend à organiser un service desk.
|
||||
48
Cours Génie Logiciel/RAD.md
Normal file
48
Cours Génie Logiciel/RAD.md
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
RAD
|
||||
========================
|
||||
*19/04/18*
|
||||
|
||||
**R**apid **A**pplication **D**evelopment
|
||||
|
||||
## Cycle de vie
|
||||
|
||||
* Initialisation
|
||||
* Cadrage
|
||||
* Conception
|
||||
* Construction
|
||||
* Mise en oeuvre
|
||||
|
||||
Pas plus de 120 jours par cycle
|
||||
|
||||
## Structure de développement
|
||||
|
||||
C'est une méthode Agile.
|
||||
Méthode SADT
|
||||
|
||||
## Approfondissement des phases
|
||||
|
||||
Y a plusieurs phases, avec des documents liés à chacune.
|
||||
|
||||
### Inconvénients du RAD
|
||||
|
||||
Il parle de recherche d'emploi, je sais pas pouruqoi. Das l'idée, ça fait partie des grosses compétences recherchées dnas le métier :
|
||||
|
||||
- gestion de projet
|
||||
- rigueur et méthode
|
||||
- esprit d'analyse
|
||||
- rédaction d'un cahier des charges
|
||||
- méthodes agiles
|
||||
|
||||
## RAD2
|
||||
|
||||
...
|
||||
|
||||
## Une base de référence ?
|
||||
|
||||
Après RAD2 sont arrivé des méthodes liées
|
||||
|
||||
* DSDM
|
||||
* SCRUM
|
||||
* UP
|
||||
* ASD et FDD
|
||||
|
||||
81
Cours Génie Logiciel/SOA.md
Normal file
81
Cours Génie Logiciel/SOA.md
Normal file
|
|
@ -0,0 +1,81 @@
|
|||
SOA
|
||||
========================
|
||||
|
||||
Service Oriented Architecture
|
||||
|
||||
## HistoriqueHistorique
|
||||
|
||||
jusqu 90, les trucs étaient sur des gros serveurs (mainframe) en arhci monolothiques
|
||||
|
||||
en 90 est apparu le client/serveur avec l'appartition / la démocratisation des PC
|
||||
Puis distribué années 2000
|
||||
|
||||
### Client / serveur
|
||||
|
||||
soit cnetré sur le client, soit centré su rle servur. Schéma sur PDF. Réseau entre es dux, l'un a plus de charge que l'autre.
|
||||
Le problèm : dépendances, biblioth_ques, api à importer...
|
||||
|
||||
|
||||
#### Application web
|
||||
|
||||
Très ouvertes/ fcails à déplyer
|
||||
|
||||
#### cloud computing
|
||||
|
||||
Location d'ordi pour que les autres se dédouanent de la gestion
|
||||
|
||||
|
||||
|
||||
Ca a été très centralisé, puis moins avec client/serveur, puis on es tpassé au distribué
|
||||
|
||||
## Les architectures de service
|
||||
|
||||
### Principaux composants
|
||||
|
||||
Un service : un composant, une fonctionnalité d'un SI mis à disposition ds clients.
|
||||
Il fonctionne ne boite noire : on se fout de savoir comment il fonctionne. On le vuet performant, robuste, et indépendant de notre contexte (n tant que client)
|
||||
|
||||
### solution métier
|
||||
L'utilisateur ne s'intéresse pas au service mais à l'applicatio qui utilise ce service. On en a deux la backend et la frontend. Tout ça compose la "solution métier"
|
||||
|
||||
### SOA 1.0
|
||||
|
||||
né dnas les années 2000. Première génération
|
||||
Né d'un besoin fort de se connecter ua beosin.
|
||||
|
||||
avantage : ouverture du SI
|
||||
inconvénient : les dev ont pris le monoplithe tel quel et mis des servics autour : pas de robustesse et de performance
|
||||
|
||||
### SOA 2.0
|
||||
|
||||
architecture microservice
|
||||
|
||||
ce qui change, c'est la façon de voir son entreprise :
|
||||
chaque section devient un service. Vision "verticale"
|
||||
|
||||
inconvénient : le microservice a une durée de vie courte. Ca change très vite, faut pouvoir suivre la cadence. plein de services dans des technos différentes,
|
||||
|
||||
### SOA 3.0
|
||||
|
||||
devient un truc de mode : tout le monde en veut et veut un truc multi partenaires
|
||||
Avec l'essort des objets connectés on évolue vers des archis plus reactives et besoin de temps réel
|
||||
|
||||
on rajoute par rapport à la précédent eune couche IoT, qui communiquera directement avec les obj connectés, et plusieurs gestionnaires, APÏ pour interface rles différents servies entre eux, ainsi qu'un gestionnaire d'PAI.
|
||||
|
||||
on a encore deux parties front/back
|
||||
|
||||
Archi plus complexe car besoins ont évolué
|
||||
|
||||
## Idées reçues
|
||||
|
||||
SOA liée à techno ou protocole particuliers : ** FAUX**
|
||||
Lié à un outil : **FAUX** (si on utilise par exemple un esp, un répartisseur de mssage utilisé par quelqu'un d'autre en SOA, il ne sera pas forcément en SOA)
|
||||
SOA n'est pas égal à web service ou micro service
|
||||
Un web service n'est pas non plus un SOA
|
||||
SOA se réfléchi, c'est pas adapté à tout
|
||||
|
||||
|
||||
## Conclusion
|
||||
|
||||
SOA c'est un esemble de concepts et de pratqiues qui permettent de mettre en place une architecture.
|
||||
Nécessite d eraisonner sur archi de l'application, la méthodologie mise ne oeuvre. Et tout organisation n'est pas adapté au SOA
|
||||
55
Cours Génie Logiciel/XP.md
Normal file
55
Cours Génie Logiciel/XP.md
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
XP
|
||||
========================
|
||||
|
||||
Rappels d'agiles
|
||||
|
||||
Historique
|
||||
|
||||
créé en 1999 par 3 chefs de projet . débuté en 96 à la bas eun système de calcul des rémunéraitons
|
||||
Doit être le plus simple possible : KISS
|
||||
|
||||
Principe : faire simple et efficace au plus possible.
|
||||
|
||||
travail direct avec le client sur des cycles très court. travail en binôme
|
||||
Méthode non révolutionnair,e mais pousse les 12 principes d'agile à l'extrême
|
||||
|
||||
## Valeurs
|
||||
tout le monde travaille ensmbl : bcp de communication et de respect. Autorité très respectée
|
||||
Faire simple
|
||||
|
||||
tests d'acceptance sont réalisés par le clint
|
||||
tests unitaires sont utilisés par toutes méthodes d'agile
|
||||
|
||||
## Pratiques
|
||||
Le dev se préoccupe donc pas du produit final, mais just du dev. En cas d'erreur ils ont toujours les feedboack
|
||||
réunions fréquente sou pas mal de trucs sont décidés (planning game)
|
||||
client très intégré, il srt de "beta tester"
|
||||
metaphore : scénario global qui sert de
|
||||
rythmr : pas plus de 40h de travail par semaine
|
||||
convention de nommage unique pour tout l'équipe pour garantir compréhension du code
|
||||
|
||||
## roles
|
||||
|
||||
petites équipes en XP (5 max)
|
||||
vérificateur s'assure que la commmunication dnas l'équipe est ok, peut éve,tuellmeent demander aide
|
||||
client écrit les user story
|
||||
développeur définissent tache ingénirie, tmps pour les fair,e iplémntent stories et test unitaires
|
||||
tester implémente les test fonctionnles réalisés
|
||||
coach planifie les réunions, note résultats, est le mentor de l'équipe mais ne dit pas comment travailler. Supervise mais chacun reste autonome
|
||||
|
||||
Un membre de l'équipe peut avoir plusieurs roles (tout n'est pas compatible)
|
||||
|
||||
## Planification et gestion
|
||||
|
||||
Un planning de livraison est réalisé permettant de réaliser un planning d'itération. Réunion au début d'une itération pour produire le planning
|
||||
|
||||
## Conception et développement
|
||||
|
||||
on les garde simple : on se base sur une petite partie à chaque fois.
|
||||
solutions pointues pour réduire erreurs et éviter d'ajouter fonctionnalités inutiles : on vise l'utile à l'instant t
|
||||
|
||||
## Recommandations
|
||||
|
||||
une rétrospective au moins toutes les 3 itérations
|
||||
|
||||
une des méthodo les plus utilisées
|
||||
123
Cours Management des SI/Cours 1 - Chapitre 1.md
Normal file
123
Cours Management des SI/Cours 1 - Chapitre 1.md
Normal file
|
|
@ -0,0 +1,123 @@
|
|||
Cours 1 - Chapitre 1
|
||||
========================
|
||||
|
||||
# Intro
|
||||
|
||||
Présentation des SI
|
||||
Ce qu'est le SI
|
||||
|
||||
Un SI se renouvelle environ tous les 3 ans. Un SI c'est analyser les besoins de l'entreprise et adapter l'infrastucture et le réseau à celui ci
|
||||
|
||||
Partiel : 4h étude de cas dans laquelle on doit répondre à des questions.
|
||||
Questions de cours (un peu)
|
||||
Pour le reste, étude de cas
|
||||
|
||||
I - Généralités, partie introductive
|
||||
II - pour cours 2. Abord les trucs qu'il faut avoir au minimum. Les 4 fonctionnalités de base que tout SI doit a voir
|
||||
III
|
||||
|
||||
# I - Notion de système d'information
|
||||
|
||||
## 1 - Le système organisationnel
|
||||
|
||||
Définition de systèm dans le cours (PDF p10)
|
||||
|
||||
### L'organisation est un système
|
||||
|
||||
Il y a plusieurs profils :
|
||||
|
||||
* l'entreprise
|
||||
notion de profit
|
||||
* les établissements publics, collectivités territoriales, associations
|
||||
pas de but lucratif
|
||||
|
||||
Dans les deux cas il y a des exigences communes :
|
||||
|
||||
* gestion des ressources
|
||||
* qualité de production
|
||||
* politique/stratégie/identité/structure
|
||||
|
||||
C'est grâce à la couche process qu'on arrive à optimiser, réduire les coûts, **gagner de l'argent** !
|
||||
|
||||
### Les trois systèmes composants de l'organisation
|
||||
|
||||
* Le système **opérationnel** : coeur de métier, crée le produit
|
||||
* Le système de **controle et de pilotage** (décisionnel)
|
||||
pilotage de la performance : CPM (Corporat Performance Management).
|
||||
* Le système d'**information** :
|
||||
fait l'intermédiaire entre les deux système précédents, pour assurer le bon transfert de l'information
|
||||
permet de maintenir l'environnement interne et externe de l'entreprise
|
||||
|
||||
|
||||
## 2 - Place et rôle du SI au sein de l'organisation
|
||||
|
||||
son but est de transférer l'information. L'information pertinente et adéquate en fonction des personnes et des décisions à prendre.
|
||||
|
||||
On parle de SI (Information), ne pas confondre avec Informatique où on parle TIC : Technologies de l'Information et de la Communication.
|
||||
SI lié au moyens : postes informatiques, personnel insérant les données...
|
||||
|
||||
### SI et technologie de l'information
|
||||
4 points essentiels :
|
||||
|
||||
* Saisie des donnés
|
||||
* Traitement des donnés
|
||||
* Stockage des donnés
|
||||
* Communication des données
|
||||
|
||||
aujourd'hui en plus du rôle de "pont", tranfert, le SI a un role de mémoire
|
||||
mémoire : histoire, savoir et savoir-faire
|
||||
on appel ce stockage sur le long terme la capitalisation de l'expérience >> ça rapporte à l'entreprise
|
||||
|
||||
### Le rôle du SI
|
||||
|
||||
Il doit aussi assurer un rôle de mise en forme de données
|
||||
=> c'est pour ça que tout le monde s'oriente vers le BI reporting
|
||||
Permet d'avoir accès directement et uniquement à l'information qui nous concerne. >> ce qu'il faut au bon moment
|
||||
=> on crée de la valeur à partir de la donnée.
|
||||
c'est pour cette raison que bcp d'entreprises s'orientent vers les CRM ajd (Customer Relationship Management) : ils collectent des infos pour les fidéliser (ex: carte de fidélité)
|
||||
|
||||
**spirale mutuelle de données entre oganisations et information** (PDF p26)
|
||||
|
||||
### Caractéristiques du SI
|
||||
|
||||
|
||||
**Trou fonctionnel** : les entreprises en ont environ 20%
|
||||
|
||||
On essaye aujourd'hui même d'automatiser certaines décisions.
|
||||
|
||||
On a aussi des informations de type "informel" : à l'oral, pas sur le SI, mais qu'il faut prendre en compte.
|
||||
Pour les intégrer, il faut dans le SI une notion d'alerte ou d'attention, c'est le rôle du DSI qui doit alerter et proposer un traitement
|
||||
|
||||
### Qualité du SI
|
||||
|
||||
* rapidité de transmission
|
||||
* Fiabilité de la transmission
|
||||
* rendre le SI évolutif (vision dynamique de l'entreprise )
|
||||
* réduire complexité pour le rendre agile
|
||||
|
||||
### Limites du SI
|
||||
|
||||
Toutes les informations sont pas traitables par SI. Ex : réseaux sociaux. Le SI est alors pas en adéquation. Il ne peut pas stocker données qui ne sont pas structurées. Le nouveau système de big data permet de répondre à cette limite du SI
|
||||
|
||||
### La DSI
|
||||
|
||||
La DSI, c'est l'ensemble des utilisateurs du SI, du directeur à l'utilisateur
|
||||
|
||||
### La gestion du cycle de vie du SI par la DSI
|
||||
....
|
||||
phase de maturité
|
||||
|
||||
Relations entre DSI et responsables métiers = relation entre MOE et MOA
|
||||
Relation entre DSI et direction générale =
|
||||
-> échec d'un projet est du en majeure partie à une mauvaise entente entre DSI et direction
|
||||
Relation entre DSI et users = conduite du changement, soit être proche des users
|
||||
|
||||
### La structure de la DSI
|
||||
|
||||
plus entreprise importante, plus DSI est importante
|
||||
|
||||
aujourd'hui DSI ne peut pas être une personne qui gère tout ! informaticien = trop généraliste, ne veut plus rien dire
|
||||
on doit avoir une structure de la DSI avec des spécialités et une organisation derrière
|
||||
|
||||
|
||||
## 3 - Position de la fonction informatique au sein de l'organisation
|
||||
5
Cours Management des SI/Cours 2 - Chapitre 2.md
Normal file
5
Cours Management des SI/Cours 2 - Chapitre 2.md
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
Cours 2 - Chapitre 2
|
||||
=======================
|
||||
|
||||
*19/04/18*
|
||||
|
||||
53
Cours Management des SI/TD2.md
Normal file
53
Cours Management des SI/TD2.md
Normal file
|
|
@ -0,0 +1,53 @@
|
|||
TD2
|
||||
========================
|
||||
|
||||
*19/04/18*
|
||||
|
||||
|
||||
## Présenter le projet de façon synthétique
|
||||
|
||||
Le projet vise à améliorer le système de réservation actuel de l'entreprise > proactif
|
||||
L'enjeu est d'améliorer la rentabilité en améliorant le remplissag des trains via des tarifs spécifiques, une meilleure gestion de la répartition et de la réservation.
|
||||
Sans ça, le système devienra obsolète et ne collera plus à la dmeande actuelle en matière de réservation, de conccurence et d'adaptation aux contraintes internationales, de tarification...
|
||||
Les utilisateurs devraient y trouver plus de flexibilité, des tarifs plus attractif spour les plus jeunes, des plateformes simples à utiliser pour les plus vieux, un service adapté aux besoins pour tous.
|
||||
|
||||
|
||||
### Correction
|
||||
|
||||
* Stratégie du marché à partir contexte actuel >> Réactif
|
||||
* Doit moderniser son système de réservation pour rpondre au besoin du marché et exploiter au mieux les nouvelles technologies proposées par le marché. >> Stratégie réactive
|
||||
* Arrivée du logiciel SERVERUS via la société HAL
|
||||
* Objectifs, opportunités : accroitre compétitivité, meilleure réactivité face aux concurrents
|
||||
* Risques initiaux : mauvais choix de sous-traitant, mauvaise définition des besoins
|
||||
* Risques mise en production : Résistance au changement
|
||||
|
||||
## Principaux types d'actions possibles
|
||||
|
||||
Il va falloir moderniser les guichets pour s'assurer que les postes soient adaptés au nouveau logiciel. Renouvellement de la flotte = cout ! Ou au moins nettoyage et uniormisation des postes.
|
||||
formation des guichetiers pour savoir utiliser ua mieux nouveaux outils
|
||||
|
||||
Prévenir les utilisateurs sur Internet que le système va changer (en avance). Prévoir des tutoriels d'utilsation montrant comment accéder à chaque fonctionnalité existant anciennement sur la nouvelle interface. Aussi tuto de présentation de la nouvelle interface.
|
||||
|
||||
Le logiciel ne doit plus rien laisser paraitre qui laisse penser au monde du transport aérien >> culture ferroviaire mise en avant pour séduire personnel et éviter résistance au changement
|
||||
|
||||
Une interface spécial pour les guichets doit être prévue, facilitant l choix de différente soptions, la gestion de cas complexes. Travailler avec les guichetiers et faire des tests avec eux pour obtenir un outil qui colle le mieux possible à leur besoin.
|
||||
|
||||
### Correction
|
||||
|
||||
* Formation et implication de l'intégralité des utilisateurs
|
||||
* Garder dans un coin l'ancien système pour pouvoir garder anciens clients et les fidéliser : période de transition, les informer. >> Mettre en place assistance technique
|
||||
* Faire intervenir les acteurs à chaque phase du projet, pour prendre en compte les besoins
|
||||
* Mise en place du projet : Assurer un suivi et une mise en place selon méthode agile pour s'assurer que tout se passe bien.
|
||||
|
||||
Il faut toujours s'assurer dans la conduite d'un projet des impacts sur les clients et sur les employés
|
||||
|
||||
* si employés, les impliquer dans l'élaboration du projet
|
||||
* si client, assurer phase transition et assistance spécifique
|
||||
|
||||
Dans le cas d'un prestataire, garantir une mise en place en méthode agile.
|
||||
|
||||
Méthode :
|
||||
etude existant
|
||||
contexte
|
||||
risques/opportunités (avant et après mise en prod)
|
||||
impacts
|
||||
119
Cours Management des SI/TP 1.md
Normal file
119
Cours Management des SI/TP 1.md
Normal file
|
|
@ -0,0 +1,119 @@
|
|||
TP 1
|
||||
========================
|
||||
|
||||
# risques et opportunités
|
||||
|
||||
## 1 - Détermination du périmètre
|
||||
|
||||
**Définir le SI existant**
|
||||
|
||||
* 33 collaborateurs
|
||||
* Locaux dans un hotel particulier (plusieurs étages mais même lieu)
|
||||
* Employés vont travailler dans entreprise cliente
|
||||
* applications standards
|
||||
* applications sur-mesures : gestion de porjet, gestion de clientèle, paye, gestion des temps et activités, informatique. Non-intégrées et non interopérables, peu évolutives. Bases de données différentes
|
||||
* Vingt postes clients
|
||||
* OS Windows 98
|
||||
* Connexion Internet peu sécurisée
|
||||
|
||||
// Correction
|
||||
Existant
|
||||
|
||||
* 33 personnes
|
||||
* progiciel
|
||||
* hétérogène
|
||||
|
||||
|
||||
** périmètre du projet : modalités d'utilisation de l'application ARCA **
|
||||
|
||||
* doit regrouper tous les outils nécessaires aux différents postes des collaborateurs (gestion projet, clientèle, paye...)
|
||||
* doit être portable pour utilisation chez client
|
||||
* doit garantir interopérabilité entre outils
|
||||
* Doit tourner sous windows 98
|
||||
|
||||
// Correction
|
||||
Cible
|
||||
|
||||
* homogène
|
||||
* progiciel ARCA : ERP spécialisé métier. Progiciel développement lié au contexte métier pour lequel on utilise : gestion intenre, comptabilité...
|
||||
|
||||
**Enjeux pour le cabinet**
|
||||
|
||||
* Unification des outils et ressources
|
||||
* meilleure efficaxcité, facilité de transmission et d'échange de l'informaiton
|
||||
* facilité de gestion, unification de l'information dnas une même base
|
||||
* possibilité de travailler sur information et évolutivité pour adapter aux différents besoins métiers
|
||||
|
||||
|
||||
// Correction
|
||||
* Hausse de la productivité
|
||||
* Meilleur pilotage projet
|
||||
* Coût (maintenances spécifiques)
|
||||
* Réglementation assurée
|
||||
* Sécurité assurée
|
||||
* Compétitivité accrue
|
||||
* Satisfaction client
|
||||
|
||||
|
||||
|
||||
## 2 - risques et opportunités
|
||||
|
||||
* l'applicaiton ne répond pas totalement aux beosins métiers : il faudra envisager de compléter par une autre application ou faire évoluer l'application. dans ce cas, il faudra soit embaucher des gens pour le développer soit payer les foncitonnalités supplémentaires
|
||||
* l'application est dificilement évolutive et deviendrait vite obsolète. Il faudrait alors à nouveua changer le foncitonnement du SI et reformer les gens
|
||||
* l'application est complexe à utiliser et nécessite d'embaucher une main d'oeuvre plus qualifiée ou de payer des formation. Ca peut entrainer un cout important, prnedre du tmps de formation impactant le travail des employés, implique de recruter à priori.
|
||||
* certians employés ne sont pas assez à l'aise avec l'outil inormatiqu pour utiliser corectmeent l'application. Il faudra alors les "replacer" ou les foutre au placard
|
||||
* certains emplyés refusent de quitter le tout papier. Faudra les virer c'est chiant
|
||||
|
||||
//Correction
|
||||
deux types d'opportunités et de risques : lors de la création et lors de la mise en production. Là on cherche lors de la mise en oeuvre
|
||||
|
||||
Opportunités :
|
||||
|
||||
* Faire participer tous les acteurs de l'entreprise en collaboration >> Réussite de la mise à niveau du système
|
||||
|
||||
Risques :
|
||||
|
||||
* sous-estimer la taille du projet
|
||||
* mauvais choix de technologie
|
||||
* mauvaise ou pas d'évolutivité : elle ne correspondra rapidement plus au besoin
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Les enjeux
|
||||
|
||||
## 1 - enjeux techniques
|
||||
|
||||
* pour quitter le tout papier, il faudra investir dans une flotte de postes clients portables. Changer l'OS pour une version plus récente peut être assez cool.
|
||||
* Ca serait aussi l'occase de sécuriser la ligne Internet, invesitr dna sun réseua sécurisé pour garntir la confidentialité des données.
|
||||
* Mettre à jour outils de base (suite bureautique...)
|
||||
|
||||
//Correction
|
||||
Architecture technique :
|
||||
|
||||
* Mise à niveau du système d'exploitation
|
||||
* évolution des serveurs
|
||||
* appareil actifs pour le réseau et la sécurité
|
||||
* augmentation du nombre de postes
|
||||
* augmenter le débit du réseau (pour connexion à distance entre autres)
|
||||
|
||||
Architecture informatique :
|
||||
|
||||
* mise en place d'un progiciel de type ARCA : architecture n-tiers, interfaces web, cohérence des données
|
||||
|
||||
## 2 - impact sur les pratiques
|
||||
|
||||
* euh... bah c'est bien ça unifie tout
|
||||
* ça permet de faciliter la circuliation, la structure et l'accès à l'information
|
||||
* centralise les données, plus simple à maintenir et à exploiter
|
||||
* oblige collaborateurs à changer pratiques
|
||||
* apprentissage nouveau truc : formation et changement d'habitude
|
||||
* boost d'efficacité si tout se passe bien
|
||||
|
||||
//Correction
|
||||
|
||||
* Meilleur contrôle des flux de travail
|
||||
* Amélioration des conditions de travail (normes audit, suivi procédures, suivi calendrier...impact pratiques des collaboratuers : il est possible d'entrer plus dans le détail)
|
||||
|
||||
|
||||
203
Cours Marketing digital/Cours 2.md
Normal file
203
Cours Marketing digital/Cours 2.md
Normal file
|
|
@ -0,0 +1,203 @@
|
|||
Cours 2
|
||||
========================
|
||||
_29/03/18_
|
||||
|
||||
#### 2 - La segmentation (cibler ses utilisateurs)
|
||||
Il y a plusieurs types de rendement (primaire, secondiare, tertiaire, quaternaire...)
|
||||
Rendement tertiaire le plus intéressant : celui où on vend produit.
|
||||
|
||||
|
||||
#### 3 - L'automatisation des processus marketing
|
||||
|
||||
Ou **marketing automation **
|
||||
Boucle :
|
||||
créer une liste de cibles
|
||||
exécuter la commande
|
||||
mesurer les comportements
|
||||
segmentation basée sur l'activité
|
||||
attirer les leads qualifiés
|
||||
identifier les leads qualifiés
|
||||
analyser les performances
|
||||
|
||||
**automatisation à travers : **
|
||||
botchat
|
||||
publications auto et unifiées sur réseaux sociaux
|
||||
systèmes de commande vocale
|
||||
|
||||
#### 4 - La gestion des données personnelles
|
||||
|
||||
Les internautes sont de plus réticents à donner leurs données perso
|
||||
Ils sont quand même pas si cons (j'émet des doutes là dessus). Plus l'entreprise manque de transparence, plus elle fragilise tout son bouzin.
|
||||
|
||||
#### 5 - Le permission marketing
|
||||
|
||||
raté les infos :(
|
||||
|
||||
## II - L'impact du digital sur le marketing
|
||||
|
||||
Le marketing digital n'est qu'un service supplémentaire : dans ce cas il devient une sous-couche supplémentaire et optionnelle du marketing
|
||||
Globalement il a une dimension transversale et est plus qu'un outil supplémentaire : il revisite complètement l'apporche marketing
|
||||
|
||||
Bcp d'entreprises utilisent encore le digital comme un moyen de limiter les interactions avec le client, et de le "mettre de côté". Les sites ne sont alors que des vitrines, il n'y a personne pour répondre derrière.
|
||||
|
||||
Mix marketing = plan de marchéage (4P)
|
||||
|
||||
### A - Le marketing mix augmenté par la digitalisation
|
||||
|
||||
#### 1 - Produit
|
||||
|
||||
On peut grace au digital énormément compléter l'offre de conseil et de services (ex : faire des tutos sur internet)
|
||||
|
||||
#### 2 - Prix
|
||||
|
||||
On peut fixer le prix par rapport
|
||||
|
||||
* aux coûts
|
||||
* mais aussi à l'offre (concurrents)
|
||||
ex : la fnac vend certains produit par rapport au prix d'amazon (genre pas plus de 15% plus cher...) >> redéfinition de la "zone de chalandie" autour des magasin avant (brick and mortar)
|
||||
* la demande (élasticité prix/demande) : deltaD/deltaP*100
|
||||
permet de voir si on a pas une forte rentabilité à baisser le prix ou bien si on peut les monter
|
||||
prend en compte prix "magique" (9,99), prix psychologique (prix max/min qu'on est prêt à payer)
|
||||
* gratuits (on reviendra dessus)
|
||||
|
||||
Vis à vis de tout ça, le digital favorise l'adaptabilité, l'ajustement dynamique du prix. **Yield management** = tarification flexible
|
||||
Le Yield marche très bien pour une offre de service périssable pour laquelle on a des frais fixes élevés (ex : nuit d'hotel). Le Louvre par ex. s'y est mis
|
||||
On peut aussi faire des promotions spécifiques : que sur internet, ou bien faire des pubs sur internet pour des promos uniquement en magasin.
|
||||
|
||||
#### 3 - Place
|
||||
|
||||
Aujourd'hui l'évolution tend vers le click and mortar : les pure player ouvrent des magasins, les brick and mortar se digitalisent. >> modèle qui marche le mieux
|
||||
|
||||
#### 4 - Promotion (communication)
|
||||
|
||||
Deux aspect de communication media :
|
||||
|
||||
* creation pub
|
||||
* plan média
|
||||
|
||||
Communication hors media :
|
||||
|
||||
* marketing direct
|
||||
* evenementiel
|
||||
* dossier de presse
|
||||
|
||||
Création pub coute moins cher que plan média. Ce qui coute cher c'est surtout location d'espace publicitaire.
|
||||
|
||||
Le catalogue ikea par exmple est du "hors média". Ce qui est média est ce qui passe par des mass media.
|
||||
marketing direct - un des poste les plus important des entreprises. à partir d'un fichier client, action mise en place. Il faut travailler sur ce fichier client, le construire, le mettre à jour, l'acheter. Pour faire fichier client on peut agréger données (web cool pour ça), ou bien à partir fichier déclaratif (on a accepté de répondre à questionnaire)
|
||||
|
||||
### B - Le markting mix enrichi par la digitalisation
|
||||
|
||||
#### 1 - People (relation client)
|
||||
Ce qui devient intéressant c'est la com participative
|
||||
On essaye de créer des amabasseurs, des représentants de la marque. On crée de la discussion entre la marque et les clients.
|
||||
|
||||
#### 2 - Personnalisation
|
||||
|
||||
On s'intéresse à l'expérience globale de l'utilisateur, plus uniquement sur l'interaction du client avec le produit, mais à tout ce qu'il a eu en amont.
|
||||
-> Formulaire de satisfation client : on veut savoir comment ça s'est passé.
|
||||
|
||||
Personnalisation est un enjeu majeur du numérique : on colle mieux au besoin client, on fait de l'offre modulable, on intègre des variations (formules, fonctionnalités, personnalisation produit...).
|
||||
**Cibler - Segmenter - moduler** : trois axes de la personnalisation
|
||||
|
||||
#### 3 - Physical evidence
|
||||
|
||||
Sur internet, l'offre est intangible : il n'y a pas de matérialisation. Ceci est générateur de stress pour le client. Il y a donc un travail sur la matérialisation du service, du produit : il faut être _réel_
|
||||
C'est d'autant plus important si la notoriété n'est pas établie
|
||||
|
||||
#### 4 - Permission marketing
|
||||
|
||||
Tout est axé autour de la donnée personnelle. D'ailleurs il y a RGPD créé pour ça.
|
||||
L'ancienne directive abroge ancienne directive datant de 95.
|
||||
résultat de 4 ans de débats et affaires :
|
||||
|
||||
* 2014 CJCE : Google : droit au référencement
|
||||
* 2015 Safe Harbod : protection face à l'import des données privés aux USA
|
||||
|
||||
Le RGPD fait la distinction entre "donnée personnelle" et "donnée sensible"
|
||||
Toute collecte est interdite sans "consentement éclairé"
|
||||
entreprise concernée est toute entreprise qui collecte, manipule données.
|
||||
Amende : le plus élevé entre 20M€ et 4% du CA (plafond)
|
||||
garanti la portabilité et l'extraction des données
|
||||
Garanti le droit à l'oubli
|
||||
Droit d'être informé en cas de piratage de données
|
||||
Et concept de class action introduit dans RGPD : internautes peuvent être défendus par des associations dans le cadre d'actions de groupe
|
||||
|
||||
### C - Les étapes du parcours client : outbound et inbound marketing
|
||||
|
||||
#### 1 - La distinction Outbound / Inbound
|
||||
|
||||
c'est le B.A.BA
|
||||
|
||||
**Inbound**
|
||||
Approche consistant à faire venir le consommateur à soi
|
||||
Processus inclusif : on propose du contenu interessant, de la vidéo amusante qui sera partagée... on gagne l'attention via du contenu pertinent qui est proposé et via lequel on engage le dialogue
|
||||
=> lead maturing
|
||||
|
||||
Stratégie :
|
||||
Attirer > Convertir > Vendre > Fidéliser
|
||||
étrangers > visiteurs > prospects > clients > ambassadeurs
|
||||
|
||||
L'entreprise cherche à attirer à convertir, sans pour autant parler : on cherche la relation avant tout
|
||||
On ne peut pas se passer d'inbound
|
||||
|
||||
**Outbound**
|
||||
On va chercher le consommateur, on cherche avant tout la transaction
|
||||
|
||||
Il ne faut pas utiliser que l'inbound, les deux se confortent
|
||||
|
||||
#### 2 - Le parcours client
|
||||
|
||||
Foutre
|
||||
|
||||
On reprend la stratégie de l'inbound, et on repère 4 objectifs
|
||||
|
||||
* Attirer
|
||||
Owned Media : offre de contenu que l'on possède (page FB, blog...).
|
||||
publicité
|
||||
* convertir
|
||||
on veut transformer un visiteur en un prospect. Il le devient à partir du moment où il laisse une trace : il entre dans notre fichier prospect (case cochée, adress laissée). _il faut demander la permission !_
|
||||
* conclure
|
||||
sur internet c'est beaucoup plus dur qu'en vrai. Il faut utiliser des outils, des leviers. Beaucoup utilisent le téléphone pour faciliter, déclencher l'achat,réassurer. Il faut être patient et multicanal pour transformer un prospect en client.
|
||||
on peut mettre en place un principe de scoring : inscription newsletter 3pts, rencontre sur salon : 8pts... quand le prospect arrive à un certain nombre de points, on peut prendre contact avec lui. ça permet de rationnaliser le niveau de proximité que la personne a avec la marque. ça s'automatise en plus assez facilement
|
||||
* réenchanter (fidéliser)
|
||||
Créer un cercle vertueux entre la marque et le client
|
||||
Gérer la relation clint après la vente
|
||||
|
||||
### D - L'expérience client Globale
|
||||
#### 1 - Le ZMOT
|
||||
"Zero Moment of Truth"
|
||||
passe ensuite au first moment et au second moment
|
||||
ZMOT->FMOT->SMOT
|
||||
|
||||
l'utilisateur va aller quand il est intéressé chercher de l'info sur un produit. C'est une étape clé.
|
||||
FMOT: achat du produit
|
||||
SMOT : expérience du produit
|
||||
|
||||
On touche à l'e-reputation. C'est plus dur à maitriser, à contrôler que la réputation.
|
||||
ce sont les SMOT qui nourrissent les infos du ZMOT
|
||||
|
||||
#### 2 - L'articulation du physique et du numérique
|
||||
|
||||
* "web-to-store"
|
||||
= ROPO (reasarch online purchase offline)
|
||||
=> attention au ropo inversé : le client se renseigne en magasin et va acheter sur internet (chez concurrent moins cher par exemple)
|
||||
|
||||
* phygital
|
||||
alliance du physic et du digital
|
||||
lieu physique peut être un lieu de distribution, de collecte (drive par ex), on peut aussi faire de la réservation en magasin sans obligation d'achat, de la géolocalisation intérieure pour trouver articles facilement... on a crée une nouvelle articulation entre ces deux couches
|
||||
|
||||
### Bilan
|
||||
|
||||
Le digital intervient plus ajd mais complète, enrichi marketing traditionnel. Il en augmente aussi les possibilités.
|
||||
|
||||
Le marketing-mix et ses 4P (approche trad) est complété par nouvelles notions (4 nouveaux P)
|
||||
|
||||
l'inbound fait venir consommateur vers la marque grace au contenus qui ont valeur pour le client
|
||||
|
||||
l'outbound va chercher le consommateur, va le pousser à faire quelque chose à travers messages, offres
|
||||
|
||||
Le numérique offre au consommateur possibilité de rechercher par lui meme les informations (le ZMOT). Attention à ne pas manipuler via ZMOT, il se méfie de plus en plus. on pense que ça se dirige de plus en plus vers les réseaux sociaux pour aller chercher l'info
|
||||
|
||||
Les magasins ne sont pas morts, le numérique renforce leur poids en leur donnant du sens, en améliorant relation client, les vendeurs deviennent conseillers...
|
||||
|
||||
68
Cours Marketing digital/Cours 3.md
Normal file
68
Cours Marketing digital/Cours 3.md
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
Cours 3
|
||||
========================
|
||||
|
||||
*19/04/18*
|
||||
|
||||
Rappels cours précédent :
|
||||
alliance physique et numérique - exemple d'ikea. Plus d'avenir pour magaisns préiurbains. Ils construsent en centre ville en faisant lien entre physique et digital
|
||||
|
||||
## III Business models et strategies e-marketing
|
||||
|
||||
### A - Le Bait and Hook
|
||||
|
||||
il s'agit d'identifier les sources de création de valeur. Les facteurs clés / succès.
|
||||
Selon les marchés, il faut appliquer plusieurs stratégies (DAS)
|
||||
On a pour cela développé depuis les annés 50des outils pour ça (outils de gestion de valeur du marché).
|
||||
Martice BCG = tableua de 4 cases avec ordonnées : position commerciale, abcisses : valeur du marché
|
||||
|
||||
| + | -
|
||||
:-------|:--------------:|----------:
|
||||
+ | vedettes | dilemnes
|
||||
- | vache à lait | poids mort
|
||||
|
||||
-> voir schéma sur feuille
|
||||
|
||||
Razor Blade Model = inventé par Gillette apparemment. Premiers à faire du Bait and Hook.
|
||||
|
||||
Bait : vendre un produit à perte ou sans gain d'argent
|
||||
Hook : Valoriser avec un surprix des biens et services additionnels
|
||||
|
||||
En gros, on finance un produit avec le second.
|
||||
|
||||
Raisons qui ont poussé à repesé les business models au dela du bait and hook :
|
||||
|
||||
4 - l'instantabilité - chronocompétition féroce dans le marketing numérique.
|
||||
|
||||
### B - Les plateformes d'intermediation
|
||||
|
||||
Effets de réseau / retombées de réseau / externalités de réseau : plus il y a d'acteurs sur le réseau, plus le produit a de la valeur.
|
||||
|
||||
* commission
|
||||
* abonnement
|
||||
* publicité
|
||||
* La longue traine : les quelques "tête d'affiche" des produits les vendus qui génèrent gros CA sont pas plus rentables que les milliers d'articles moins bien vendus mais beaucoup plus nombreux.
|
||||
|
||||
Problématique de ces plateforme :
|
||||
|
||||
* qui paye ?
|
||||
Identifier les catégories d'acteur pour savoir celle qui a le plus intérêt à se mettre en relation avec l'autre ? >> C'est elle qui paiera
|
||||
* comment attirer les deux partis ?
|
||||
* comment définir le point mort ?
|
||||
= seuil de rentabilité. déterminé dans le cadre d'une action marketing, c'est le CA, le volume d'activité à atteindre pour être rentable. Il dépend d'une structure de couts et par la projection planifiée de l'évolution de notre activité.
|
||||
|
||||
Ces plateformes ont un nombre conséquent de moyens de se rémunérer maisça peut prendre très longtemps avant de trouver l bon business model (exemple de Waze qui en a testé 7 d'affillée)
|
||||
|
||||
### C - Les modèles de gratuit
|
||||
|
||||
#### Le gratuit contre pub
|
||||
"Si c'est gratuit, c'est vous le produit"
|
||||
Google, Facebook en sont friands : données pointues sur leurs utilisateurs, ce qui leur permet de mieux connaitre les consommateurs que les autres. Chez google, algo de déduction prédictif très efficace
|
||||
|
||||
#### Le freemium
|
||||
|
||||
Gratuit à usage limite, parfois contraint.
|
||||
usage restreint genre x utilisations par mois, x minutes, x exports de fichiers, capacité limitée (HD)
|
||||
|
||||
### D - L'abonnement
|
||||
|
||||
C'est un concept de premium pur. L'abonnement connait un succès croissant.
|
||||
73
Cours Télécomm&VoIP/Cours 2.md
Normal file
73
Cours Télécomm&VoIP/Cours 2.md
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
Cours 2
|
||||
========================
|
||||
|
||||
(On DL VulnVoIP sur Vulnhub)
|
||||
|
||||
Quand on fiat une connexion entre deux téléphone, on a d'abord une connexion SIP
|
||||
puis une négo pour établissement RTP
|
||||
puis choix codecs
|
||||
|
||||
À chaque fois qu'un téléphoine reçoit un messgae init, il va initier un truc mais j'ai zappé quoi.
|
||||
|
||||
|
||||
**DOS**
|
||||
quand message init (SIP) :
|
||||
-> syn
|
||||
-> synack
|
||||
=> pas de ack (on commence un truc qui termine pas en sorte)
|
||||
==> monopolise les ressources, bloqu le système
|
||||
|
||||
Les flux RTP dsécurisés permettent de s prémunir du man in the middle.
|
||||
SIP fait circuler en clair, on peut donc encaspuler pour la sécurité (c'est ça ls fulx rtp sécurisés ?)
|
||||
Le Man in the middle est possible sur des connexions cablées via du sppof MAC
|
||||
|
||||
## au niveau du serveur
|
||||
...
|
||||
|
||||
|
||||
# Install et pratique sur vulnVoip avec un kali linux
|
||||
|
||||
logs kali : root // toor
|
||||
|
||||
outils utiles :
|
||||
n map (zen map)
|
||||
=> check
|
||||
|
||||
- du réseau
|
||||
- d'une machine
|
||||
|
||||
nmap -sV -os ..... IPcible/24
|
||||
|
||||
armitage front-end sur metasploit
|
||||
=> "hail macy" (??)
|
||||
|
||||
Configurer les exploits à utiliser
|
||||
RHost R : remote (cible)
|
||||
LHost L : Local (assaillant)
|
||||
|
||||
|
||||
|
||||
Fichiers sympa :
|
||||
|
||||
- /etc/passwd
|
||||
- /et/shadow
|
||||
|
||||
Pour casser mots de passe :
|
||||
|
||||
- Hydra
|
||||
- John the Ripper
|
||||
|
||||
Foncitonnent avec bases de mdp connues (rockyou.txt ???)
|
||||
|
||||
Pour rechercher arborescence sur petit serveur web ou autre :
|
||||
|
||||
- dirb -> sur serveur web, fait des petits tests pour voir ce qui est accessible
|
||||
|
||||
Pour scanner réseau : `netdiscover`
|
||||
Après avoir chopé l'ip de l'ordi cible, Guillaume sent le caca, on scane le sports ouverts :
|
||||
`nmap -sV IPcible`
|
||||
Je vais voir ensuite du côté du serveur web, puisqu'il y a un port 80 ouvert
|
||||
Y adeux liens, je scanne tout ce tintouin avec wapiti : `wapiti http://192.168.56.102:80/`
|
||||
wapiti ca marche pas, je tente John the ripper mais je comprend rien
|
||||
je tente ensuite hydra, j'arrive à jouer avec mais rien ne marche
|
||||
je désespère et abandonne
|
||||
262
Markdown Cheatsheet.md
Normal file
262
Markdown Cheatsheet.md
Normal file
|
|
@ -0,0 +1,262 @@
|
|||
Markdown Cheatsheet
|
||||
===================
|
||||
|
||||
This cheatsheet is intended as a quick reference and showcase of the markdown syntax in [QOwnNotes](http://www.qownnotes.org).
|
||||
|
||||
## Headers
|
||||
|
||||
```markdown
|
||||
# H1
|
||||
## H2
|
||||
### H3
|
||||
#### H4
|
||||
##### H5
|
||||
###### H6
|
||||
|
||||
Alternatively, for H1 and H2, an underline-ish style:
|
||||
|
||||
Alt-H1
|
||||
======
|
||||
|
||||
Alt-H2
|
||||
------
|
||||
```
|
||||
|
||||
# H1
|
||||
## H2
|
||||
### H3
|
||||
#### H4
|
||||
##### H5
|
||||
###### H6
|
||||
|
||||
Alternatively, for H1 and H2, an underline-ish style:
|
||||
|
||||
Alt-H1
|
||||
======
|
||||
|
||||
Alt-H2
|
||||
------
|
||||
|
||||
|
||||
## Emphasis
|
||||
|
||||
```markdown
|
||||
Emphasis, aka italics, with *asterisks* or _underscores_.
|
||||
|
||||
Strong emphasis, aka bold, with **asterisks** or __underscores__.
|
||||
|
||||
Combined emphasis with **asterisks and _underscores_**.
|
||||
```
|
||||
|
||||
Emphasis, aka italics, with *asterisks* or _underscores_.
|
||||
|
||||
Strong emphasis, aka bold, with **asterisks** or __underscores__.
|
||||
|
||||
Combined emphasis with **asterisks and _underscores_**.
|
||||
|
||||
|
||||
## Lists
|
||||
|
||||
(In this example, leading and trailing spaces are shown with with dots: ⋅)
|
||||
|
||||
```markdown
|
||||
1. First ordered list item
|
||||
2. Another item
|
||||
⋅⋅* Unordered sub-list.
|
||||
1. Actual numbers don't matter, just that it's a number
|
||||
⋅⋅1. Ordered sub-list
|
||||
4. And another item.
|
||||
|
||||
⋅⋅⋅You can have properly indented paragraphs within list items. Notice the blank line above, and the leading spaces (at least one, but we'll use three here to also align the raw Markdown).
|
||||
|
||||
⋅⋅⋅To have a line break without a paragraph, you will need to use two trailing spaces.⋅⋅
|
||||
⋅⋅⋅Note that this line is separate, but within the same paragraph.⋅⋅
|
||||
|
||||
* Unordered list can use asterisks
|
||||
- Or minuses
|
||||
+ Or pluses
|
||||
```
|
||||
|
||||
1. First ordered list item
|
||||
2. Another item
|
||||
* Unordered sub-list.
|
||||
1. Actual numbers don't matter, just that it's a number
|
||||
1. Ordered sub-list
|
||||
4. And another item.
|
||||
|
||||
You can have properly indented paragraphs within list items. Notice the blank line above, and the leading spaces (at least one, but we'll use three here to also align the raw Markdown).
|
||||
|
||||
To have a line break without a paragraph, you will need to use two trailing spaces.
|
||||
Note that this line is separate, but within the same paragraph.
|
||||
|
||||
* Unordered list can use asterisks
|
||||
- Or minuses
|
||||
+ Or pluses
|
||||
|
||||
|
||||
## Links
|
||||
|
||||
There are two ways to create links.
|
||||
|
||||
```markdown
|
||||
[I'm an inline-style link](https://www.google.com)
|
||||
|
||||
[I'm an inline-style link with title](https://www.google.com "Google's Homepage")
|
||||
|
||||
[You can use numbers for reference-style link definitions][1]
|
||||
|
||||
URLs and URLs in angle brackets will automatically get turned into links in the preview.
|
||||
http://www.example.com or <http://www.example.com>
|
||||
|
||||
[1]: http://www.qownnotes.org
|
||||
```
|
||||
|
||||
[I'm an inline-style link](https://www.google.com)
|
||||
|
||||
[I'm an inline-style link with title](https://www.google.com "Google's Homepage")
|
||||
|
||||
[You can use numbers for reference-style link definitions][1]
|
||||
|
||||
URLs and URLs in angle brackets will automatically get turned into links in the preview.
|
||||
http://www.example.com or <http://www.example.com>
|
||||
|
||||
[1]: http://www.qownnotes.org
|
||||
|
||||
|
||||
## Inline code and code blocks
|
||||
|
||||
```markdown
|
||||
Inline `code` has `back-ticks around` it.
|
||||
```
|
||||
|
||||
Inline `code` has `back-ticks around` it.
|
||||
|
||||
Blocks of code are either fenced by lines with three back-ticks, or are indented with four spaces.
|
||||
|
||||
```markdown
|
||||
s = "Code with space indent"
|
||||
print s
|
||||
```
|
||||
|
||||
s = "Code with space indent"
|
||||
print s
|
||||
|
||||
|
||||
## Tables
|
||||
|
||||
Tables aren't part of the core Markdown spec, but the QOwnNotes preview supports them.
|
||||
|
||||
```markdown
|
||||
Colons can be used to align columns.
|
||||
|
||||
| Tables | Are | Cool |
|
||||
| ------------- |:-------------:| -----:|
|
||||
| col 3 is | right-aligned | $1600 |
|
||||
| col 2 is | centered | $12 |
|
||||
| zebra stripes | are neat | $1 |
|
||||
|
||||
There must be at least 3 dashes separating each header cell.
|
||||
The outer pipes (|) are optional, and you don't need to make the
|
||||
raw Markdown line up prettily. You can also use inline Markdown.
|
||||
|
||||
Markdown | Less | Pretty
|
||||
--- | --- | ---
|
||||
*Still* | `renders` | **nicely**
|
||||
1 | 2 | 3
|
||||
```
|
||||
|
||||
Colons can be used to align columns.
|
||||
|
||||
| Tables | Are | Cool |
|
||||
| ------------- |:-------------:| -----:|
|
||||
| col 3 is | right-aligned | $1600 |
|
||||
| col 2 is | centered | $12 |
|
||||
| zebra stripes | are neat | $1 |
|
||||
|
||||
There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and you don't need to make the raw Markdown line up prettily. You can also use inline Markdown.
|
||||
|
||||
Markdown | Less | Pretty
|
||||
--- | --- | ---
|
||||
*Still* | `renders` | **nicely**
|
||||
1 | 2 | 3
|
||||
|
||||
|
||||
## Blockquotes
|
||||
|
||||
```markdown
|
||||
> Blockquotes are very handy in email to emulate reply text.
|
||||
> This line is part of the same quote.
|
||||
|
||||
Quote break.
|
||||
|
||||
> This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can *put* **Markdown** into a blockquote.
|
||||
```
|
||||
|
||||
> Blockquotes are very handy in email to emulate reply text.
|
||||
> This line is part of the same quote.
|
||||
|
||||
Quote break.
|
||||
|
||||
> This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can *put* **Markdown** into a blockquote.
|
||||
|
||||
|
||||
## Horizontal Rule
|
||||
|
||||
```markdown
|
||||
Three or more...
|
||||
|
||||
---
|
||||
|
||||
Hyphens
|
||||
|
||||
***
|
||||
|
||||
Asterisks
|
||||
|
||||
___
|
||||
|
||||
Underscores
|
||||
```
|
||||
|
||||
Three or more...
|
||||
|
||||
---
|
||||
|
||||
Hyphens
|
||||
|
||||
***
|
||||
|
||||
Asterisks
|
||||
|
||||
___
|
||||
|
||||
Underscores
|
||||
|
||||
## Line Breaks
|
||||
|
||||
```markdown
|
||||
Here's a line for us to start with.
|
||||
|
||||
This line is separated from the one above by two newlines, so it will be a *separate paragraph*.
|
||||
|
||||
This line is also begins a separate paragraph, but...
|
||||
This line is only separated by two trailing spaces and a single newline, so it's a separate line in the *same paragraph*.
|
||||
```
|
||||
|
||||
Here's a line for us to start with.
|
||||
|
||||
This line is separated from the one above by two newlines, so it will be a *separate paragraph*.
|
||||
|
||||
This line is also begins a separate paragraph, but...
|
||||
This line is only separated by two trailing spaces and a single newline, so it's a separate line in the *same paragraph*.
|
||||
|
||||
## Comments
|
||||
|
||||
```markdown
|
||||
[comment]: # (This comment will not appear in the preview)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
Credit: [markdown-here](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet)
|
||||
License: [CC-BY](https://creativecommons.org/licenses/by/3.0/)
|
||||
82
Markdown Showcase.md
Normal file
82
Markdown Showcase.md
Normal file
|
|
@ -0,0 +1,82 @@
|
|||
Markdown Showcase
|
||||
=================
|
||||
|
||||
Another header
|
||||
-------------
|
||||
|
||||
Let's see _if the emphasis
|
||||
|
||||
carries over_ to __another__ paragraph.
|
||||
|
||||
And ` maybe this ` should <i>Hello</i> not be
|
||||
|
||||
> ### Header
|
||||
>
|
||||
> Header
|
||||
> --------
|
||||
>
|
||||
|
||||
- - -
|
||||
|
||||
* List 0
|
||||
* List
|
||||
* Hello!
|
||||
|
||||
Hello
|
||||
|
||||
Item 2
|
||||
Hello
|
||||
|
||||
Hibuli habuli!*Code here*
|
||||
|
||||
* Item 3
|
||||
|
||||
* Hello again
|
||||
|
||||
Hassd *code*
|
||||
|
||||
Code here
|
||||
|
||||
1. Stuff
|
||||
|
||||
Hello
|
||||
|
||||
Markdown FTW!
|
||||
|
||||
|
||||
1986\. What a great season. A link here: <http://www.example.com/> that should be automatically detected.
|
||||
|
||||
Stuff *here!*. This is pretty cool.
|
||||
|
||||
* Hello
|
||||
* Booboo
|
||||
|
||||
What [up to the ][name] cats n dogs :) He*ll*o!! *Some emphasized* stuff here. A * star * has [born]. This * i dont know what*will happen.
|
||||
|
||||
1. Stuff
|
||||
1. Hello
|
||||
9. Again
|
||||
3211233. Stuff
|
||||
|
||||
This is [an example](http://example.com/ "Title") inline link.
|
||||
|
||||
``Hello **`strong text** here``
|
||||
|
||||
> These * should * not \*be\* selected. This* neither! *should be. This *neither should\* be*
|
||||
|
||||
# 2nd Headline
|
||||
|
||||
Yeah.
|
||||
|
||||
[name]: http://google.com
|
||||
[foo1]: http://example.com/ "Optional Title Here"
|
||||
[foo3]: http://example.com/
|
||||
"'Optional Title Here"
|
||||
|
||||
|
||||
Some code
|
||||
|
||||
|
||||
Third headline
|
||||
-------------------
|
||||
Some stuff here...
|
||||
Loading…
Reference in a new issue