fbpx
Guide Gratuit

Do you speak technique ?

Comprendre et maîtriser les principaux concepts techniques du digital : de la méthodologie de projet, aux principales architectures techniques web et mobile en passant par les API ou bien encore les bases de données… Vous saurez tout ce que vous n’avez jamais osé demander sur la technique !

Recevoir le livre blanc

Dans ce guide, découvrez :

  • Les approches méthodologies et projet
  • Les principes fondamentaux d'architecture technique
  • Les Stacks les plus classiques
  • Les différentes base de données
  • Les échanges de données par API
  • Les technologies mobiles et cross-platform
  • Et encore plus de technique ! Cache, moteur d'indexation, sécurité,...
Soyez incollable sur les bases du digital avec notre série “Comprendre la tech”

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.

Les approches méthodologiques et projets

Avant de rentrer dans la technique, détaillons quelques deux approches qui son de plus en plus répandues et les différentes méthodologies de gestion de projet.

Note : le propos n’est pas de critiquer ou de comparer ces approches/méthodologies mais juste de présenter les concepts et le vocabulaire qui y sont associés.

Approche « Minimum Viable Product » ou MVP

L’approche MVP consiste à réduire le temps entre le démarrage du projet et sa mise sur le marché. Cette approche est souvent associée à une méthodologie agile. Elle consiste principalement à répondre à la question : « Quelles sont les fonctionnalités indispensables à mon produit pour le mettre sur le marché ? ». Ainsi toutes les fonctionnalités accessoires vont être écartées.

L’avantage principal de cette approche est d’accélérer le « time-to-market », de capitaliser sur les retours des premiers utilisateurs (les « early adopters ») et évidemment de réduire le coût du développement de la solution. La principale critique est que produire une solution parfois incomplète ne permet pas d’avoir une réelle validation du concept. Contre toute attente, ce sont parfois les fonctionnalités accessoires qui font le succès d’une solution.

Approche « Mobile first »

Cette approche vise à concevoir l’application mobile en premier. Un projet web a souvent une déclinaison mobile. Concevoir l’application mobile d’abord permet de simplifier l’application au maximum. Ce qui est assez proche de l’approche MVP. En effet, sur mobile, l’expérience utilisateur doit être la plus claire possible. Les fonctionnalités « nice-to-have » ne seront pas présentes et les chemins de navigation réduits au minimum. Il y a donc beaucoup de chance que votre application soit plus efficace et que son développement soit plus simple.

La méthode agile (SCRUM très souvent)

Mener des développements est une tâche complexe. Il est donc nécessaire de mettre en place une bonne méthodologie pour le faire aboutir. Deux sont assez diffusées : le cycle en V ou waterfall et la méthode agile (très souvent SCRUM mais il existe de nombreuses déclinaisons).

La méthode agile propose une approche itérative. Le Product Owner, appelé en général « le PO », est le responsable de l’avancement du produit, il définit les fonctionnalités, les correctifs que l’on regroupe dans un « Product backlog ». Le projet est découpé en « sprints » de deux ou trois semaines en général. Il a pour objectif de développer un sous-ensemble d’éléments, le « Sprint backlog ». Puis le sprint comprend l’ensemble des étapes pour produire la solution : conception (design), développement (build), tests et démonstration/rétrospective (review). Chaque jour, le Scrum Master organise une réunion nommée mêlée quotidienne ou encore « daily scrum» qui permet de faire le point sur ce qui a été fait et les difficultés rencontrées.

Cette méthodologie est employée lorsque le contour du projet n’est pas forcément bien défini. Il permet de rapidement produire les premiers éléments de la solution ce qui fonctionne plutôt bien avec l’approche MVP.

La méthode Waterfall ou Cycle en V

Le cycle en V propose une approche globale. Au départ, on définit le projet complet et donc le périmètre précis de l’application. Chaque étape de la descente du V permet de définir de plus en plus finement l’application jusqu’à aboutir aux développements. Chaque étape de la remontée du V permet de passer des cycles de tests de plus en plus complets jusqu’à la mise en production. Cette méthodologie est employée lorsque l’on sait ce à quoi il faut aboutir. Elle présente l’avantage de permettre une estimation fine des délais et des budgets. Lorsqu’il y a un prestataire en jeu, cela permet de l’engager au forfait (c’est-à-dire pour un prix fixé à l’avance). L’inconvénient est le temps de développement puisqu’il faut tout faire d’un coup, on parle alors « d’effet tunnel ».

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)

Pour lire la suite,
recevez notre livre blanc