Livre Blanc

Do You Speak Technique ?

Introduction

Les développeurs ont imaginé un jargon qui est souvent hermétique pour les profanes… Alors si vous êtes en relation avec des développeurs et que vous vous sentez parfois perdus, c’est normal. Chaque métier possède ses codes que ce livre blanc propose de décrypter.

Nous espérons qu’une fois que vous aurez lu ce document, vous pourrez assister à une réunion où l’on parle de technique sans être profondément ennuyé ou vous sentir dépassé ! Avec un peu d’effort (et ce document), vous pourrez engager une discussion sans complexe.

A propos de ce livre blanc

Ce livre blanc fait partie d’une série “Comprendre la tech” qui vise à faire comprendre au plus grand nombre les principaux concepts techniques. La précédente version a été téléchargée plus de 2 000 fois depuis son lancement en 2016 ! Merci à tous les lecteurs de ce livre blanc qui nous ont fait des remarques ou proposés des idées. Votre contribution est précieuse !

Cette version a été améliorée pour préciser les principales stacks techniques (vous découvrirez ce qui se cache derrière ce terme barbare dans ce document) et mettre à jour la partie mobile.

Il s’adresse à tous les acteurs du digital qui ne connaissent pas la technique : product owner, directeur de projet, designer, UX, DSI, responsable innovation. Bref, tous ceux qui souhaitent comprendre ce qui est en jeu dans les projets digitaux des entreprises comme par exemple le développement d’un nouveau projet de plateforme web, une application mobile etc.

Principes fondamentaux de l'architecture technique

Front/Back : un piège pour les non-initiés

Attention au 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 backoffice les gestionnaires.

Quelle est la différence entre un framework et une librairie ?

Un framework n’est pas une librairie ! Si l’amalgame est assez facile à faire entre ces deux termes, c’est tout simplement parce que dans la plupart des cas, un framework inclut une
ou plusieurs librairies.

Ainsi, si une librairie peut être comparée à un ensemble de fonctionnalités, un framework quant à lui peut être perçu comme la structure complète d’un projet ! Ainsi le développeur va appeler une librairie pour disposer de fonctionnalités particulières. Par exemple, notre librairie Open Source Gotenberg permet de transformer n’importe quelle page HTML en document PDF.

Inversement, un framework va permettre de structurer le code pour le développeur en gérant de nombreux aspects tels que la sécurité par exemple. La différence entre un framework et une librairie est donc appelée « Inversion of Control (IOC) » ce qui signifie de manière concrète qu’un framework « contrôle » le code d’un développeur alors qu’une librairie est «contrôlée » par le code d’un développeur.

Parmi les frameworks les plus connus on retrouve : Symfony ou Laravel (PHP), Angular (Javascript), Django (Python), Ruby on Rails (Ruby), … Et cela marche pour tous les langages de programmation !

Architecture client/serveur ou 3 tiers

On oppose souvent les architectures client léger – 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).

Il y a fort fort longtemps, les débits réseaux ainsi que les ressources serveurs étaient faibles (dans les années 80-90). Une partie des traitements était donc déportée vers les clients (PC des utilisateurs). Depuis, 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 des traitements qui sont effectués sur les devices (le matériel) des utilisateurs en utilisant les navigateurs ou les OS des mobiles. On cherche à améliorer les performances ou pallier une 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.

Le design pattern 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-VueContrôleur) est l’un des plus importants. Il s’agit d’un pattern qui sépare la logique du code en trois parties afin de clarifier la conception des développements :

• Le Contrôleur gère l’enchainement des pages, les URL… (le code PHP qui interroge le modèle et renvoie les éléments à afficher à la vue)
• 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)