Accompagnement de personnalités, conseil et Audit de sûreté et sécurité.

o Gestion du personnel
o Organisation des tournés Conventionnée o Gestion de la flotte et de l’administratif

Développeur web,

HTML/CSS. Sass, bootstrap,
JavaScript ReactJs
NodeJs
MongoDB, Mongoos
Python = en cours d'apprentissage

Participe à la défense National
Participe à divers Formation Militaire o Participe à l' Opération Sentinelle

o Mission Variable o Chauffeur Livreur o Magasinier

o Participe à la défense National
o Formation Général Initial Militaire

Développer un scripte afin de répondre à une demande d'analyse de marché.

Scraper un site avec plus de 1000 livre.

Le scripte devra créer 2 dossiers et intégrer les donnés récupérer dans des fichiers.csv classé par catégories de livre.

Architecture

--env
--gitignore
--scrypt.py

-- Datas
-----fichier1.csv
-----fichier2.csv
-----etc.
--image
----img1.jpg
----img2.jpg
----img3.jpg
----etc...

Technologies
● Le développement devra se faire en CSS, sans JavaScript.
● Aucun framework ne devra être utilisé, en revanche l’utilisation de SASS serait un
plus.
● Aucun code CSS ne devra être appliqué via un attribut style dans une balise HTML

La cible étant les personnes connectées et pressées, le site sera développé en utilisant
l’approche mobile-first. Pour cette raison, seules des maquettes mobiles seront réalisées.
Sur tablette et desktop, le site devra s’adapter, mais ces supports n’étant pas prioritaires,
leur mise en page est libre.
● L’ensemble du site devra être responsive sur mobile, tablette et desktop.
● Les pages devront passer la validation W3C en HTML et CSS sans erreur.
● Le site doit être parfaitement compatible avec les dernières versions desktop de
Chrome et Firefox.

Architecture générale
L’application web sera composée de 4 pages :
● Une page d’accueil montrant (de manière dynamique) tous les articles disponibles à
la vente.
● Une page “produit” qui affiche (de manière dynamique) les détails du produit sur
lequel l'utilisateur a cliqué depuis la page d’accueil. Depuis cette page, l’utilisateur
peut sélectionner une quantité, une couleur, et ajouter le produit à son panier.
● Une page “panier”. Celle-ci contient plusieurs parties :
○ Un résumé des produits dans le panier, le prix total et la possibilité de
modifier la quantité d’un produit sélectionné ou bien de supprimer celui-ci.
○ Un formulaire permettant de passer une commande. Les données du
formulaire doivent être correctes et bien formatées avant d'être renvoyées au
back-end. Par exemple, pas de chiffre dans un champ prénom.
● Une page “confirmation” :
○ Un message de confirmation de commande, remerciant l'utilisateur pour sa
commande, et indiquant l'identifiant de commande envoyé par l’API.
Planification de tests
Planifiez une suite de tests d’acceptation pour couvrir l’ensemble des fonctionnalités listées
dans ce document (spécifications fonctionnelles et techniques Kanap).

Site web D'ajout et de comparaison de Sauces

Piiquante se dédie à la création de sauces épicées dont les recettes sont gardées.
Secrètes. Pour tirer parti de son succès et générer davantage de buzz, l'entreprise
Souhaite créer une application web dans lequel les utilisateurs peuvent ajouter.
Leurs sauces préférées et liker ou disliker les sauces ajoutées par les autres.

API Routes
Toutes les routes sauce pour les sauces doivent disposer d’une autorisation (le
token est envoyé par le front-end avec l'en-tête d’autorisation : « Bearer <token> »).
Avant que l'utilisateur puisse apporter des modifications à la route sauce, le code
doit vérifier si l'userId actuel correspond à l'userId de la sauce. Si l'userId ne
correspond pas, renvoyer « 403: unauthorized request. » Cela permet de s'assurer
que seul le propriétaire de la sauce peut apporter des modifications à celle-ci.

Exigences de sécurité
● Le mot de passe de l'utilisateur doit être haché.
● L'authentification doit être renforcée sur toutes les routes sauce requises.
● Les adresses électroniques dans la base de données sont uniques et un
plugin Mongoose approprié est utilisé pour garantir leur unicité et signaler
les erreurs.
● La sécurité de la base de données MongoDB (à partir d'un service tel que
MongoDB Atlas) ne doit pas empêcher l'application de se lancer sur la
machine d'un utilisateur.
● Un plugin Mongoose doit assurer la remontée des erreurs issues de la base
de données.
● Les versions les plus récentes des logiciels sont utilisées avec des correctifs
de sécurité actualisés.
● Le contenu du dossier images ne doit pas être téléchargé sur GitHub.

1 - Analyse de l’état actuel de SEO du site fourni.
Ajouter la bonne pratique à mettre
en place pour chaque partie du site qui n’est pas optimisée.

2. Amélioration du SEO du site.
   Optimiser le site en appliquant 10
   recommandations à son contenu et à son code source. fournir le
   code source complet de la version améliorée du site.
   Le site doit passer le W3C pour le HTML et CSS

3. Comparaison des résultats.
   La vitesse de chargement des pages du site a un impact
   sur les résultats de recherche.
   fournire un un rapport d’optimisation.

Spécifications fonctionnelles
● Les usagers pourront rechercher des hébergements dans la ville de
leur choix. Le champ de recherche est un champ de saisie, le texte
doit donc pouvoir être édité par l’utilisateur. Il faut englober ce
champ dans un formulaire pour que ce dernier soit valide auprès du
W3C. La partie recherche ne doit pas être fonctionnelle.
● Chaque carte d’hébergement ou d’activité devra être cliquable dans
son intégralité (pas uniquement le titre). Pour l’instant, les liens sont
vides. On peut utiliser un attribut href=”#” pour simuler la
présence d’un lien.
● Les filtres doivent changer d’apparence au survol. Je te laisse décider
de l’effet approprié, je n’ai pas encore eu le temps de me pencher
dessus. Par contre, ils ne doivent pas être fonctionnels.
● Les textes “Hébergements” et “Activités”, situés dans l’en-tête, sont
des liens. Ils doivent mener respectivement vers la section
“Hébergements à Marseille” et “Activités à Marseille”.

Spécifications techniques
● Deux maquettes ont été réalisées : l’une desktop et l’autre mobile. Le
site devra être également adapté aux formats tablette. Pour les
tablettes, nous sommes libres de faire les adaptations nécessaires. Il
est important qu’aucun élément ne soit coupé, et que le texte ait
une taille suffisante.
● Concernant les breakpoints, nous avons convenu avec le designer UI
d’utiliser 992 px et 768 px.
992 px pour les écrans d’ordinateurs et 768 px pour les tablettes, et
tout ce qui est en dessous de 768 pour les téléphones portables.
● Il faut d’abord réaliser l’intégration pour les ordinateurs (autrement
dit, en desktop first), puis les tablettes et enfin les téléphones.
L’utilisation des Media Queries nous permettra de réaliser
l’intégration pour les différents supports.
● Plusieurs formats et tailles d’images ont été exportés. Il faudra choisir
le format le plus adapté par rapport à la résolution et au temps de
chargement.
● Les icônes proviennent de la bibliothèque Font Awesome. Nous
pouvons passer par un CDN pour faciliter le chargement des icônes.
● Les couleurs de la charte sont le bleu (#0065FC), une version plus
claire de ce bleu (#DEEBFF) et le gris pour le fond (#F2F2F2).
● La police du site est Raleway. Nous pouvons passer par Google Font
pour importer facilement cette police dans le code :
https://fonts.google.com/specimen/Raleway.
● Il est important d’utiliser les pixels et les pourcentages plutôt que les
REM et les EM.
● Il est important d’utiliser Flexbox plutôt que Grid car c’est la techno
que l’équipe maîtrise le mieux.
● Aucun framework CSS (type BootStrap ou Tailwind CSS) ou
préprocesseur CSS (type Sass ou Less) ne doit être utilisé.
● Il est important d’utiliser des balises sémantiques (type main,
header, nav, etc.).
● Le code doit être valide aux validateurs W3C HTML et CSS.
● La maquette doit être compatible avec les dernières versions de
Google Chrome et de Mozilla Firefox. Il faudra tester le prototype sur
ces deux navigateurs.
● Il n’est pas nécessaire de versionner le code.