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

2. 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

3. 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.

4. 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

5. 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.

6. 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.

7. 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).

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 13
Rien que pour votre culture, voici les principaux composants (ou PACKAGES d’un
framework PHP) :

14. 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.

15. 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.

16. 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).

17. 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.

18. 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.

19. 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

20. 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.

21. 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.

22. 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 !

23. 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
contact@thecodingmachine.com
4, rue de la Michodière – 75002 PARIS