Do you speak technique ?

23
1 DO YOU SPEAK TECHNIQUE ? Tous les concepts et le vocabulaire technique du web ! Auteur : Kevin NGUYEN

Transcript of Do you speak technique ?

Page 1: Do you speak technique ?

1

DO YOU

SPEAK

TECHNIQUE ? Tous les concepts et le vocabulaire technique du web ! Auteur : Kevin NGUYEN

Page 2: Do you speak technique ?

2

INTRODUCTION 3!

1. LES PRINCIPAUX CONCEPTS 4

BON ALORS, LE WEB COMMENT CA MARCHE ? 4

CLIENT LÉGER/CLIENT LOURD 6

ARCHITECTURE MVC 7

FRONT/BACK : UN PIEGE POUR LES NON-INITIÉS 8

2. LES TECHNOS FRONT END 9

LA BASE 9

GERER LES INTERACTIONS 10

2. LES DIFFERENTES « STACKS » 11

SOLUTIONS OPEN SOURCE 11

ARCHITECTURE WEB CLASSIQUE (PHP) 12

ARCHITECURE PLUS « TENDANCE » (JAVASCRIPT) 14

3. LES BASES DE DONNÉES 15

4. LES WEB SERVICES ET LES FORMATS D’ÉCHANGES 16

5. LE MOBILE 18

TECHNOLOGIES DE DEVELOPPEMENT 18

LES TECHNOLOGIES HYBRIDES 18

6. UN PEU PLUS DE TECHNIQUE… 19

LA GESTION DU CODE SOURCE : GIT 19

LES SERVEURS, LE HOSTING 19

LA SÉCURITÉ 19

LA GESTION DU CACHE 20

LES MOTEURS D’INDEXATION 21

CONCLUSION 22

À PROPOS DE THECODINGMACHINE 23

Page 3: Do you speak technique ?

3

INTRODUCTION

En plus de coder dans un langage incompréhensible pour les non-initiés, les

développeurs ont imaginé un jargon qui leur est hermétique…

Vous êtes en relation avec des développeurs et vous vous sentez parfois perdus ?

Vous soupçonnez vos équipes techniques de délibérément employer des termes ou

des concepts que vous ne comprenez pas ? Reprenez la main ! Avec un peu d’effort

(et ce document), vous pourrez engager une discussion sans complexe.

Ce document a pour objectif de vous faire comprendre les principaux concepts

techniques et les termes employés ! Nous espérons que vous pourrez assister à une

réunion où l’on parle de technique sans être profondément ennuyé ou vous sentir

dépassé.

Le défi est de taille mais chez TheCodingMachine on n’a peur de rien ;-)

Note : notre objectif n’est pas d’expliquer comment les choix sont menés. Cela aurait

augmenté la complexité de ce document.

Page 4: Do you speak technique ?

4

1. LES PRINCIPAUX CONCEPTS

BON ALORS, LE WEB COMMENT CA MARCHE ?

« Au premier jour, Dieu créa le protocole TCP/IP* et puis, comme c’était trop compliqué de

retenir les adresses IP sur le navigateur, Dieu dit : « que le DNS soit ! » Et le DNS fut. Dieu vit

que le DNS était bon. Les requêtes http s’échangeaient bien : ce fut Internet. »

*le protocole TCP/IP permet l’échange de données sur Internet

Quand l’internaute tape une adresse d’un site web, le SERVEUR DNS (Domain Name

System) identifie le nom de domaine et renvoie vers la bonne adresse IP (adresse

physique de la machine). Dans la plupart des cas, les serveurs physiques, destinés à

héberger un serveur web, ont une IP fixe et publique (contrairement au réseau de votre

entreprise qui vous affecte une IP locale aléatoirement dans une plage d’IP). De

Page 5: Do you speak technique ?

5

manière très simplifiée, les serveurs DNS s’échangent des informations afin de fournir

la réponse.

Le serveur DNS est généralement la propriété d’un REGISTRAR (ou hébergeur de nom

de domaine en bon français). C’est auprès du REGISTRAR que vous allez acheter

votre nom de domaine et le faire pointer vers l’adresse IP de votre site web.

Une fois que l’adresse IP est résolue auprès du DNS, la connexion est établie avec les

serveurs web qui peuvent alors échanger des REQUETES HTTP (les pages de votre

site).

Dans les projets, il est possible que l’on parle de PORTS TCP. Ce sont les terminaisons

qui « écoutent » certaines applications, par exemple, les requêtes http sont affectées

au port 80, POP3 (pour les e-mails) sur le port 110 ou bien encore FTP sur le port 21

etc.

Page 6: Do you speak technique ?

6

CLIENT LÉGER/CLIENT LOURD

On oppose souvent les ARCHITECTURES CLIENT LEGER ou ARCHITECTURE 3 (N)

TIERS aux architectures CLIENT-SERVEUR ou CLIENT LOURD. On parle de client

lourd lorsque le matériel de l’utilisateur est utilisé pour les traitements tandis que l’on

parle de client léger lorsque l’ensemble des traitements est effectué à distance (sur un

serveur web par exemple).

Lorsque le web n’était pas aussi prégnant, que les débits réseaux ainsi que les

ressources serveurs étaient faibles (dans les années 80-90), une partie des

traitements était déportée vers les clients (PC des utilisateurs).

Avec l’amélioration des capacités des navigateurs et des connexions internet, les

architectures client léger se sont imposées.

Aujourd’hui, on revient un peu en arrière avec les technologies front-end (expliqué ci-

dessous) ou les applications natives (IPhone ou Android) qui fonctionnent sur le

modèle client lourd pour améliorer les performances ou pallier à la déficience

éventuelle de réseau.

Parfois, par extension ou facilité, on parle aussi d’ARCHITECTURE 3 TIERS pour

évoquer les différents composants physiques de la solution : le terminal (navigateur

web ou téléphone), le serveur web et le serveur de données.

Page 7: Do you speak technique ?

7

ARCHITECTURE MVC

Il y a des problèmes en programmation qui reviennent tellement souvent qu'on a créé

des bonnes pratiques (qui résolvent ces problèmes) que l'on a réunies sous le nom de

DESIGN PATTERN.

Le design pattern MVC ou MODEL-VIEW-CONTROLLER (Modèle-Vue-Contrôleur) est

le plus important. Il s’agit d’un pattern qui sépare la logique du code en trois parties

afin de clarifier la conception et le développement :

-! Le Modèle gère la logique métier et les données (les requêtes SQL) ;

-! La Vue affiche la page (le code HTML et quelques boucles et conditions PHP

très simples, pour afficher par exemple des listes) ;

-! Le Contrôleur gère l’enchainement des pages, les URLs… (le code PHP qui

interroge le modèle et renvoie les éléments à afficher à la vue).

Page 8: Do you speak technique ?

8

FRONT/BACK : UN PIEGE POUR LES NON-INITIÉS

Ici, il y a un piège. On peut parler de développement FRONT-END ou BACK-END en

évoquant la technologie respectivement sur le navigateur ou sur le serveur web. Mais

on peut aussi parler de FRONT-OFFICE ou de BACK-OFFICE. Et, dans ce cas, on

distingue les populations d’utilisateurs. Le Front-Office adressant les visiteurs d’un

site et le Back-Office les gestionnaires.

La même application, deux interprétations de front-back :

Et pourtant, il s’agit de la même application !

Note : un terme apparaît de plus en plus, il s’agit de FULL STACK. Cette notion indique

toutes les technologies depuis le front-end jusqu’au back-end.

Page 9: Do you speak technique ?

9

2. LES TECHNOS FRONT END

(technologies qui sont associées au navigateur).

LA BASE

Le format HTML permet de décrire la structure des pages Web. Il indique la nature des

éléments d’une page (lien, bouton, etc.) et l’organisation des blocs. La version 5,

finalisée en 2014 a apporté beaucoup de nouveautés pour définir les principaux

éléments de la page, intégrer des médias (vidéo, audio) ou fournir des éléments utiles

(saisie de dates ou de nombres).

CSS est le langage qui permet de préciser la mise en forme des balises HTML. Par

exemple la police d’affichage, la taille ou la couleur du texte, les images de fond… La

version 3 permet notamment de gérer les animations et les transitions d’état de

manière standardisée. On peut même adapter le rendu d’une même page à la taille

des écrans (ordinateur, tablette, smartphone) grâce aux media queries. C’est le

Responsive Design.

Comme les développeurs sont flemmards et en ont assez de faire toujours la même

chose, des FRAMEWORKS (ensemble cohérent de briques logicielles « prêtes à

l’emploi ») regroupant HTML, CSS et JavaScript permettent de mettre en place très

rapidement un site web. Ils implémentent notamment le « GRID SYSTEM » (système

de grille) qui assure l’alignement des éléments et pose les bases du Responsive

Design. Un des plus connus est BOOTSTRAP.

Page 10: Do you speak technique ?

10

GERER LES INTERACTIONS

La plupart des interactions qui apparaissent sur une page web sont gérées grâce au

JAVASCRIPT (un peu en CSS si vous avez bien lu le paragraphe d’avant). C’est un

langage de programmation à part entière. Evidement de nombreuses bibliothèques de

code sont apparues comme par exemple JQUERY qui a eu un grand succès ces 10

dernières années. Le slogan parle de lui-même : « code less, do more ». Il met à

disposition des développeurs des fonctions utilitaires permettant d’implémenter très

rapidement des tas d’animations (faire glisser un slider, faire apparaître une

description plus longue etc.)

Une technologie permet de faire appel au serveur sans recharger la page. Il s’agit de la

technologie AJAX. Elle permet d’effectuer des vérifications comme par exemple :

« est-ce-que l’email saisi dans un formulaire correspond à un compte existant ? ».

Evidemment, les navigateurs sont en constante évolution. CANVAS permet, par

exemple, de dessiner grâce au JavaScript. Les usages sont nombreux et peuvent aller

d’une simple palette où on dessine des carrés à un jeu très interactif.

Page 11: Do you speak technique ?

11

3. LES DIFFERENTES « STACKS »

SOLUTIONS OPEN SOURCE !Ne réinventez pas la roue ! Parfois, votre besoin correspond à une solution prête à

l’emploi. Il existe en effet de très nombreuses solutions Open Source pour répondre à

des besoins récurrents : gestion de contenus (CMS), gestion de la relation client

(CRM), et e-Commerce notamment. Les principales solutions Open Source sont

largement utilisées, et disposent d'une très large communauté de développement

assurant maintenabilité et support.

Voici un inventaire non exhaustif des principales solutions existantes :

•! CMS - CONTENT MANAGEMENT SYSTEM : DRUPAL, WORDPRESS, JOOMLA

•! CRM - CUSTOMER RELATIONSHIP MANAGEMENT : SUITECRM (FORK DE

SUGARCRM), VTIGER, ODOO (ANCIENNEMENT OPENERP)

•! E-COMMERCE : MAGENTO, PRESTASHOP, DRUPAL COMMERCE

!Ces solutions permettent de mettre en place très rapidement et à moindre coût votre

application. Cependant, la vraie question est de déterminer ce qu'il reste à développer.

Ces développements seront souvent plus complexes à réaliser car ils devront se plier

aux contraintes de la solution que vous aurez choisie.

Note : si vous choisissez une solution Open Source largement répandue, pensez à prévoir

de la mettre à jour régulièrement, car les failles de sécurité sont fortement exploitées.

Page 12: Do you speak technique ?

12

ARCHITECTURE WEB CLASSIQUE (PHP)

C'est sans doute l'architecture technique la plus utilisée sur Internet. PHP, langage de

programmation coté serveur traite les requêtes des utilisateurs. Il s'interface avec une

base de données relationnelle qui est souvent MYSQL ou POSTGRESQL pour lire ou

stocker de l'information. PHP génère ensuite le HTML qui est affiché en retour. La

plupart du temps, le serveur web Apache (ou Nginx) assure la transmission des

requêtes. Les deux frameworks PHP les plus répandus sont SYMFONY 2/3 et ZEND

FRAMEWORK 2/3.

Sachez cependant qu'un effort de standardisation est mené depuis plusieurs années,

et qu'il favorise une approche micro frameworks, c'est-à-dire que plutôt que d'installer

un seul framework et tous ses modules, il est désormais possible de prendre les

éléments qui sont les plus adaptés.

Enfin, si vous entendez parler d'une architecture (ou STACK) LAMP pas de panique, il

s'agit simplement de l'acronyme LINUX, APACHE, MYSQL, PHP.

Il existe aujourd'hui un très grand nombre de librairies PHP qui permettent de

développer rapidement les fonctionnalités récurrentes des applications web : gestion

des utilisateurs et des droits, implémentation native du MVC, gestion simplifiée des

accès aux bases de données, génération automatique de listes ou de formulaires...

Le point faible de ce genre d’architecture est la capacité à supporter une forte charge

(scalabilité) et la gestion des accès concurrents.

Page 13: Do you speak technique ?

13

Rien que pour votre culture, voici les principaux composants (ou PACKAGES d’un

framework PHP) :

Page 14: Do you speak technique ?

14

ARCHITECURE PLUS « TENDANCE » (JAVASCRIPT)

On pensait avoir trouvé une architecture universelle : un navigateur, un serveur PHP,

des bases de données MYSQL. Patatra : parfois, ce type d’architecture ne suffit plus,

l’ergonomie des sites devient de plus en plus complexe, la vitesse d’exécution de

l’affichage et des traitements est de plus en plus importante (il n’y a qu’à voir les

études faites par Google ou Amazon sur la corrélation entre le taux de transformation

et les performances), les clients qui se connectent sont de plus en plus différents

(mobiles, tablettes), le big data ou bien encore la montée en charge des applications

nécessitent de gérer d’énormes quantités de données.

Asynchrone par nature, le JavaScript y est omniprésent. Que ce soit sur le serveur

avec NODEJS (et le FRAMEWORK EXPRESS) ou bien coté client avec ANGULAR ou

encore REACTJS, cette architecture vous permet de mettre en place des interfaces

fluides et réactives. Très souvent, la persistance des données est assurée par une

base de données non relationnelle comme MONGODB ou CASSANDRA. Ce standard

porte l'acronyme de stack MEAN (MONGO, EXPRESS, ANGULAR, NODE).

!Sans conteste, il s'agit des applications les plus SCALABLES (celles qui montent en

charge le plus rapidement) car leur caractère asynchrone (désolé, on ne peut pas

employer un terme plus simple mais vous pouvez lire notre livre blanc sur Node.js)

permet de gérer facilement les accès simultanés, et les bases de données non

relationnelles sont pensées pour pouvoir tourner sur plusieurs serveurs. De plus,

l'utilisation systématique des requêtes AJAX permet de ne recharger que la partie de

la page qui doit changer, ce qui produit une expérience fluide et rapide.

Page 15: Do you speak technique ?

15

4. LES BASES DE DONNÉES

La question qui se pose ne concerne pas les caractéristiques des sauvegardes de

données mais plutôt la manière avec laquelle on les sauvegarde !

Il y a quelques années, cette question ne se posait pas. On utilisait une base de

données relationnelle (Oracle par exemple). Mais les volumes de données et même la

nature des données ont changé. C’est le fameux BIG DATA dont on parle tant.

Aujourd’hui, il est tout à fait possible voire souhaitable de conserver toutes les

informations possibles comme celles liées au comportement du visiteur d’un site

web. Avec ces informations, le visiteur qui a passé du temps sur un produit pourra

recevoir des promotions ou des relances adaptées s’il n’a pas finalisé son achat.

Le modèle SQL (MODÈLE RELATIONNEL) qui consiste à lier les données entre elles

(un client a plusieurs adresses par exemple) n’est pas bien adapté ni aux volumes ni à

ce type d’informations. Les temps de traitement sont trop longs. Aussi, apparaît le

NOSQL. Le NoSQL regroupe de nombreuses bases de données, récentes pour la

plupart, qui se différencient du modèle SQL par une logique de représentation de

données non relationnelle. Cette logique a le double avantage d'augmenter les

performances et la capacité à traiter de très grands volumes de données.

Ainsi, dans les projets, il ne faut pas opposer ces deux approches mais bien souvent

les faire cohabiter ! Cette technologie (le NoSQL) ne vise finalement pas à remplacer

les bases de données traditionnelles mais plutôt à les compléter en déportant une

partie de la charge.

Page 16: Do you speak technique ?

16

5. LES WEB SERVICES ET LES FORMATS

D’ÉCHANGE

Les échanges entre les applications sont de plus en plus nombreux. Par exemple, un

site web va permettre à un visiteur de se créer un compte, ce compte va être intégré

dans un CRM (Customer Relationship Management), s’il effectue une commande,

cette commande va être intégrée dans un ERP (Entreprise Ressource Planning) et le

paiement va se faire grâce à une intégration avec une banque. Dans tous ces cas,

pour ces échanges, on va parler de WEB SERVICE ou d’API (Application Programming

Interface).

C’est souvent une des parties les plus dures des projets. La mise en œuvre de ces

services est souvent délicate : le message a-t-il été bien consommé ? La réponse est-

elle conforme aux attentes ? etc.

Il y a quelques années (OK, un paquet d’années), les formats d’échange étaient fixes

sur un certain nombre de caractères (50 pour le prénom, 50 pour le nom, 10 pour le

numéro de téléphone et ainsi de suite). Ce n’était pas un système très souple. Donc,

on a inventé un format où les différentes informations du message étaient séparées

par un caractère spécial comme un point-virgule par exemple. Ce format est parfois

utilisé, il s’agit par exemple du FORMAT CSV (Comma-separated value) qui est sous

Excel. Ce n’était pas encore assez souple, si l’on devait ajouter une donnée, il fallait

refaire le message. Les formats d’échanges sont maintenant une suite de couples

variable-valeur potentiellement récursives comme le FORMAT XML (Extensible

Markup Language) ou JSON (JavaScript Object Notation).

Page 17: Do you speak technique ?

17

Extrêmement bien structuré et possédant de très nombreuses fonctionnalités, le

format XML a tendance à céder la place à son alter-égo JSON, qui est moins normé

mais nettement plus simple d’utilisation, et nativement compatible avec les

navigateurs.

Page 18: Do you speak technique ?

18

6. LE MOBILE

TECHNOLOGIES DE DEVELOPPEMENT

Les développements d’applications dépendent étroitement des systèmes

d’exploitation (OS) des terminaux mobiles, il y a donc :

- JAVA pour Android ;

- OBJECTIVE-C ou SWIFT pour Apple ;

- et C# pour Windows Phone.

LES TECHNOLOGIES HYBRIDES

La plupart des clients ne souhaitent évidemment pas développer une application pour

chaque OS (sauf si l’on fait quelque chose de très particulier comme un jeu par

exemple). Aussi, certains éditeurs ont eu la bonne idée de développer des

technologies nommées HYBRIDES. Le code de l’application est développé sur des

technologies web classiques HTML/CSS/JavaScript. Ce code est ensuite interprété et

compilé pour chaque plateforme. Ces outils sont par exemple : ADOBE PHONEGAP,

APPCELERATOR ou encore APACHE CORDOVA.

Page 19: Do you speak technique ?

19

7. UN PEU PLUS DE TECHNIQUE…

LA GESTION DU CODE SOURCE : GIT

Le but de ces outils est de permettre de garder un historique de toutes les

modifications effectuées au code source, d’aider à travailler en équipe et de gérer les

versions. GIT est l’outil le plus utilisé. SVN est désormais un peu vieillissant.

Vous pourrez entendre : « Il suffit de FORKER le projet pour commencer à travailler

dessus et ensuite faire une PULL REQUEST ». Ce qui signifie « faire une copie du code

source, travailler dessus et proposer à celui qui est responsable du code dans son

ensemble de relire/valider son code. »

LES SERVEURS, LE HOSTING

Les serveurs ou l’hébergement en général a aussi un vocabulaire qui lui est propre. On

parle de CLOUD (Cloud Computing pour être exact) lorsqu’on achète un service à un

fournisseur et que l’on ne se soucie pas du matériel qui est derrière. On parle de

SERVEUR DEDIE lorsqu’on loue ou achète sa machine qui ne sert que ses besoins.

Entre ces deux extrêmes, toutes les solutions sont possibles : SERVEUR MUTUALISE

lorsque l’on partage un serveur avec d’autres clients ou VPS (Virtual Private Server)

qui a toutes les caractéristiques d’un serveur dédié mais qui est en fait un serveur

virtuel ! Une des plateformes VPS parmi les plus populaires est AWS AMAZON EC2.

LA SÉCURITÉ

On ne parlera que des éléments les plus connus ou les plus critiques en termes de

sécurité. L’ATTAQUE PAR DENI DE SERVICE (DoS ou DDoS en Anglais) est

Page 20: Do you speak technique ?

20

certainement une des attaques les plus médiatisées. Elle consiste à empêcher l’accès

à un service en envoyant un nombre de requêtes très important.

Après les attaques, il y a les failles ou les vulnérabilités. A part les mises à jour qui

sont régulièrement publiées (et qu’il faut mettre en œuvre), les principaux défauts

associés à un code sont les injections SQL (on peut injecter dans un champ de

formulaire des requêtes SQL) ou les failles XSS (là, on injecte du code JavaScript). Il

existe de nombreuses autres types de failles référencées : CSRF, sensitive data

exposure… Celles-ci sont maintenues à jour dans un document publié par l’OWASP

(Open Web Application Security Project) qui fait référence en la matière.

LA GESTION DU CACHE

C’est une des problématiques les plus complexes des applications web. Le cache

permet de stocker quelque part le résultat d’un calcul complexe pour éviter d’avoir à le

refaire plus tard. Il peut s’agir d’éléments très divers, comme les droits associés à un

utilisateur, ou une page HTML. Le résultat du cache peut être stocké côté client (c’est

le cache navigateur qui héberge les fichiers CSS, JS et les images), ou côté serveur.

Le cache navigateur ne nécessite pas de technologie particulière, seulement de la

configuration du serveur Web (Apache, NodeJs, etc.). En revanche, côté serveur, il y a

plein de solutions :

APC, MEMCACHE & REDIS : ces caches stockent des données. Ils sont montés en

mémoire, ils sont très rapides d’accès.

VARNISH : ce cache stocke des requêtes web. Il stocke lui-même les ressources

statiques (fichier CSS, JS, images ou HTML) et répond très rapidement pour les servir.

Cela permet de décharger le serveur applicatif d’appels « inutiles ».

La complexité du cache est liée à son invalidation : savoir précisément quand ne pas

l’utiliser est un art maîtrisé par peu de personnes.

Page 21: Do you speak technique ?

21

LES MOTEURS D’INDEXATION

Le but d’un moteur d’indexation est d’indexer les informations (logique certes). Cela

signifie qu’il classe les données ou le contenu de documents selon un système

d’indexes pour permettre de retrouver très rapidement un ou plusieurs contenus. Leur

nom varie (APACHE SOLR, LUCENE, ELASTICSEARCH, etc.), mais on les utilise

presque toujours pour développer des moteurs de recherche performants :

•! Trouver une information dans un très grand nombre de données ;

•! Faire des recherches approximatives (tolérance à la faute de frappe) ;

•! Faire des recherches à l’intérieur de documents texte.

Page 22: Do you speak technique ?

22

CONCLUSION

La technologie est un sujet passionnant. Elle évolue, se transforme, se remet en

cause. Des barrières se dressent pour la comprendre : certains concepts et un jargon

de spécialistes. Faisons tomber ces barrières !

Nous avons tenté cette approche : « Rendez les choses aussi simples que possible,

mais pas plus simples » (Albert Einstein) et nous savons bien que le sujet est un peu

aride. Mais, avec ce document, vous avez un outil pour comprendre et dialoguer avec

vos équipes techniques.

Do you speak technique now ? N’hésitez pas à nous le dire !

Page 23: Do you speak technique ?

23

À PROPOS DE THECODINGMACHINE

TheCodingMachine accompagne ses clients sur des missions de conseil

technologique et sur des projets de développement d'applications Web avec un

engagement au forfait.

Nous sommes spécialisés dans le développement de sites Internet, d’extranets,

d’intranets, d’applications Web métiers en PHP et en JavaScript.

Fondée en 2005, TheCodingMachine a piloté plus de 350 projets. Nous travaillons

aussi bien pour des grands comptes privés et publics, pour des PME-PMI que pour

des startups. Nous avons investi dès notre création dans la R&D, ce qui nous permet

par exemple d’être à la pointe des technologies web : PHP, Node.JS, AngularJS,

streaming video etc.

www.thecodingmachine.com

Tél : 01 71 18 39 73

[email protected]

4, rue de la Michodière – 75002 PARIS