Comment l’installer :

Cela va dépendre du système d’exploitation que l’on utilise.
Sur Windows, il existe des fichiers .dll prêts à l’emploi que l’on peut directement télécharger depuis le site officiel : https://xdebug.org/download.
Il faudra ensuite placer ce fichier dans le répertoire des extensions de PHP.

Note : suivant votre configuration Windows pour effectuer du développement, il se peut que le dossier des extensions se trouve à des emplacements différents, notamment avec des environnements de développement tout-en-un comme WampServer ou Laragon.
D’ailleurs, avec WampServer, l’extension Xdebug est intégrée par défaut. Il faudra ensuite redémarrer votre environnement de développement.

Installer Xdebug sous un système linux :

Sur une installation sous Linux, Xdebug peut être installé via APT ou le gestionnaire de paquets PECL (un gestionnaire de paquets pour PHP).

i vous avez besoin d’une version spécifique de Xdebug, vous pouvez l’obtenir en la recherchant dans les dépôts de votre distribution (par exemple, sous Debian et ses dérivés).

Alternative : Compilation depuis les sources

Dans de rares cas, ou pour des besoins particuliers, il est également possible de compiler l’extension directement depuis les sources.

Problème à l’installation :

Si vous rencontrez des problèmes lors de l’installation, que vous ne savez pas quelle version choisir, ou si vous hésitez entre une version Thread Safe (TS) ou Non Thread Safe (NTS), cela dépend de la façon dont PHP est exécuté : en tant que module Apache, en mode PHP-FPM ou en CLI.
Le site officiel de Xdebug propose un assistant d’installation : https://xdebug.org/wizard,
Il vous suffit d’y copier le contenu de votre phpinfo(), et il vous indiquera la version à installer.

Fichier de configuration de Xdebug

Encore une fois, cela va dépendre de votre système d’exploitation et de votre environnement de développement.
Dans cet exemple, nous allons utiliser un système Linux (Ubuntu), mais la configuration sera la même : il faudra simplement adapter les chemins des fichiers de configuration.

La configuration peut se faire à plusieurs endroits (comme pour toute extension PHP). La première solution consiste à effectuer la configuration dans le fichier php.ini.
Cependant, PHP dispose d’un dossier spécifique pour la configuration de ses extensions, et il est recommandé de l’utiliser.

Lors de l’installation, un fichier de configuration a été automatiquement créé. Pour l’instant, il permet uniquement de charger l’extension dans le moteur PHP.

Activer ou désactiver facilement l’extension Xdebug :

Pour activer ou désactiver un module PHP, y compris un module comme Xdebug, vous pouvez utiliser les commandes suivantes, qui permettent d’activer ou de désactiver un module PHP comme Xdebug.

Paramètre de configuration de Xdebug :

Xdebug possède un grand nombre de paramètres de configuration.
Nous allons passer en revue uniquement les principaux et les plus importants.
Cependant, la documentation officielle regroupe l’ensemble des paramètres et leur fonction associée :
https://xdebug.org/docs/all_settings.

Attention : si vous avez et utilisez plusieurs versions de PHP sur votre système, la configuration devra être effectuée pour chacune d’entre elles.
De même, si vous utilisez PHP dans différents modes (FPM ou CLI), il faudra configurer Xdebug pour ces deux modes de fonctionnement.

Xdebug est une extension PHP très complète, offrant plusieurs modes et fonctionnalités pour faciliter le développement, le débogage et l’optimisation des applications PHP.
Voici un tour d’horizon des principales fonctionnalités et des modes associés :

(debug, develop, trace, profile, etc.)
Vous pouvez choisir d’activer tous ces modes ou seulement certains d’entre eux dans la configuration de Xdebug.

XDebug avec le mode debug :

Xdebug modifie la fonction intégrée de PHP var_dump() pour l’afficher au format HTML.
Elle fournit des informations structurées sur une ou plusieurs expressions, incluant leur type et leur valeur. Les tableaux sont explorés récursivement, avec toutes leurs valeurs.

À noter que Xdebug dispose également d’une fonction nommée xdebug_var_dump(), qui effectue la même opération que la surcharge de la fonction var_dump() intégrée de PHP.

En mode develop, Xdebug affiche automatiquement une stack trace détaillée à chaque erreur ou exception, ce qui permet d’identifier rapidement la chaîne d’appels ayant mené à l’erreur.
Elle indique l’emplacement dans le code et l’ordre des appels, facilitant ainsi le diagnostic.

Si l’on analyse le code source, on remarque que Xdebug formate automatiquement la sortie avec des tableaux HTML.

ans le mode debug de Xdebug, voici comment l’erreur est affichée :

Fonctionnement général du mode Debug :

Le serveur web (Nginx ou Apache) reçoit la requête et la transmet à PHP-FPM (ou au module PHP d’Apache).
PHP exécute alors le script.
En temps normal, PHP exécute simplement le code et renvoie la réponse. Mais avec Xdebug activé, le processus est modifié.

Xdebug intercepte l’exécution dès le début du script en injectant un hook dans le moteur Zend (Zend Engine).
Il vérifie alors si une session de débogage doit être démarrée, selon la configuration (start_with_request=yes ou déclenchement par trigger).

Connexion avec l’IDE

S’il doit démarrer une session, Xdebug tente de se connecter à l’IDE (PhpStorm, VSCode, etc.) via le protocole DBGp.
Si l’IDE écoute sur le port défini (par défaut 9003 avec Xdebug 3), il prend le contrôle de l’exécution du script PHP.

L’IDE peut alors :

• Interrompre l’exécution si un point d’arrêt (breakpoint) est défini
• Afficher les variables et la pile d’appels (stack trace)
• Permettre une exécution pas à pas du code

XDebug avec le mode debug :

• Placer des points d’arrêt (breakpoints) dans votre code, c’est-à-dire des lignes où l’exécution du script s’arrêtera automatiquement pour inspection.
• Exécuter le code ligne par ligne (pas à pas), ce qui permet de suivre précisément le cheminement de l’exécution et de comprendre l’état des variables à chaque étape.
• Inspecter et modifier la valeur des variables en temps réel pendant l’exécution du script.
• Visualiser la pile d’appels (stack trace), c’est-à-dire la liste des fonctions ou méthodes appelées jusqu’au point d’arrêt.

Cela permet :

• De gagner un temps précieux dans la recherche et la correction de bugs complexes.
• D’éviter l’utilisation répétée de var_dump() ou die(), rendant le processus plus propre et professionnel.
• D’améliorer la compréhension du flux d’exécution et de l’état des variables à chaque étape.

Fonctionnement avec son IDE :

Le mode debug fonctionne de pair avec l’utilisation d’un IDE. La configuration varie selon l’IDE utilisé.
Prenons ici l’exemple de VSCode, mais cela fonctionnerait tout aussi bien avec PhpStorm ou un autre éditeur.

1. Téléchargez l’extension officielle depuis le store des extensions de VSCode :
   https://marketplace.visualstudio.com/items?itemName=xdebug.php-debug
2. Allez dans la section Run and Debug (icône en forme de lecture avec un insecte à gauche, ou via le raccourci Ctrl+Shift+D).
3. Cliquez sur “Create a launch.json file” puis choisissez PHP.

Un fichier .vscode/launch.json sera alors créé avec une configuration par défaut.

Exemple :

Le paramètre xdebugSettings dans la configuration launch.json de Visual Studio Code permet de contrôler la quantité et la profondeur des données que Xdebug renvoie à l’IDE lors du débogage.
Ces réglages influencent la manière dont les variables (tableaux, objets, chaînes de caractères) sont affichées et explorées dans le panneau de débogage de VS Code.

Paramètre max_children

• Définition : Nombre maximum d’enfants (éléments) d’un tableau ou d’un objet que Xdebug renvoie lors de l’inspection d’une variable.
• Utilité : Limite le nombre d’éléments affichés dans l’IDE afin d’éviter de surcharger l’interface lorsqu’une variable contient un grand nombre d’éléments.
• Exemple : Avec max_children: 128, seuls les 128 premiers éléments d’un tableau ou objet seront affichés dans l’inspecteur de variables de VS Code.

Paramètre max_data

• Définition : Taille maximale (en octets) des chaînes de caractères renvoyées lors de l’inspection d’une variable.
• Utilité : Évite que de très longues chaînes (comme du texte brut ou du JSON volumineux) ne soient tronquées dans l’interface de débogage.
• Valeur spéciale : 1 signifie pas de limite — la chaîne complète sera affichée sans troncature.

Paramètre max_depth

Exemple : Avec max_depth: 3, Xdebug affichera les sous-éléments jusqu’à trois niveaux d’imbrication. Au-delà, l’exploration s’arrête.

Définition : Profondeur maximale d’exploration dans les structures imbriquées (tableaux ou objets).

Utilité : Contrôle jusqu’à quel niveau Xdebug va explorer et afficher les sous-éléments d’une variable complexe.

Démarrage de la session de débogage :

Vous pouvez utiliser le raccourci F5, passer par le menu Exécuter, ou cliquer sur le triangle vert pour lancer le débogage.
À ce stade, l’IDE attend la connexion du serveur.

La connexion peut se faire via :

• une requête du navigateur (le cas le plus courant),
• une requête curl,
• ou des outils comme Postman ou Insomnia, notamment pour tester une API.

Lorsque le script atteint un point d’arrêt, son exécution s’interrompt.
VS Code affiche alors la barre d’outils de débogage et met en surbrillance la ligne courante. Vous pouvez alors :

• Inspecter les variables et leur état à ce moment précis,
• Consulter la pile d’appels (stack trace) pour comprendre le chemin d’exécution,
• Modifier temporairement des valeurs si nécessaire, etc.

Contrôles de débogage

Arrêter (Stop / Shift+F5) : Termine la session de débogage.

Pas à pas (Step Over / F10) : Exécute la ligne courante et passe à la suivante, sans entrer dans les fonctions appelées.

Entrer dans (Step Into / F11) : Entre dans la fonction appelée pour la déboguer ligne par ligne.

Sortir (Step Out / Shift+F11) : Exécute le reste de la fonction actuelle et revient au niveau supérieur (appelant).

Continuer (Continue / F5) : Reprend l’exécution jusqu’au prochain point d’arrêt ou la fin du script.

Pause : Suspend l’exécution à tout moment.

Arrêter (Stop / Shift+F5) : Termine la session de débogage.

Plusieurs méthodes pour activer ou désactiver le mode Debug :

Il existe plusieurs façons de lancer une session de débogage :

• soit de manière automatique pour toutes les requêtes,
• soit à l’aide d’un déclencheur (paramètre dans une requête GET, POST ou via un cookie),
• ou encore via une fonction spécifique de Xdebug

XDEBUG_MODE=debug : active la session de débogage pour toutes les requêtes

En configurant xdebug.start_with_request=yes dans le fichier de configuration, Xdebug démarre automatiquement une session de débogage pour toutes les requêtes, sans déclencheur particulier, que ce soit via un navigateur, curl, Postman ou en CLI.
Aucun paramètre ou cookie spécifique n’est nécessaire.

✅ Idéal en développement local

Il suffit de lancer son IDE en mode écoute, puis d’exécuter le script : le débogage s’active automatiquement. Cela accélère le workflow et évite les oublis de déclencheur.

❌ À éviter absolument en production

Xdebug ralentit significativement l’exécution de chaque requête PHP, même si aucun point d’arrêt n’est atteint ou si l’IDE n’est pas en écoute.
Cela peut rendre le développement très lent, en particulier sur des projets volumineux ou des frameworks complexes.

Ce ralentissement s’explique par le fait que Xdebug, en mode debug, s’insère dans le cycle d’exécution de chaque requête PHP. Il modifie le comportement du moteur pour surveiller, tracer et collecter des informations utiles au débogage, ce qui génère un overhead de performance estimé entre 20 et 30 % sur l’exécution des scripts PHP.

XDEBUG_TRIGGER : Déclenchement manuel d’une session de débogage pour une requête spécifique

Avec cette configuration, Xdebug ne démarre une session de débogage que lorsque le déclencheur (trigger) est explicitement fourni.

Le nom du déclencheur par défaut est XDEBUG_TRIGGER.
Xdebug vérifie sa présence dans les superglobales $_ENV (variables d’environnement), $_GET, $_POST, ou $_COOKIE.

Supposons que vous ayez un fichier PHP accessible via l’URL suivante, par exemple : test.php.
Pour activer le débogueur, il suffit d’ajouter un paramètre HTTP (GET ou POST) à l’URL ou au corps de la requête.

Dans ce cas, dès que le trigger est présent dans la requête, Xdebug initie une session de débogage et tente de se connecter à votre IDE.

XDEBUG_TRIGGER : personnalisation du déclencheur de session

Vous pouvez choisir n’importe quelle valeur pour ce paramètre. Ce nom est utilisé pour identifier la session de débogage.

Si l’option xdebug.trigger_value est définie dans la configuration de Xdebug, alors la valeur fournie via XDEBUG_TRIGGER doit correspondre exactement à celle définie pour que le débogage soit activé.

Depuis Xdebug 3.1, il est possible de spécifier plusieurs valeurs via une liste séparée par des virgules.
Dans ce cas, Xdebug déclenchera une session de débogage si la valeur transmise correspond à l’une des valeurs configurées via xdebug.trigger_value.

XDEBUG_SESSION : Déclenchement manuel d’une session uniquement pour le débogage

XDEBUG_TRIGGER fonctionne quel que soit le mode activé dans Xdebug (profilage, débogage, trace, etc.).
Cependant, si l’on souhaite déclencher uniquement une fonctionnalité spécifique, il est possible d’utiliser des déclencheurs hérités dédiés à chaque mode.

Par exemple :

• XDEBUG_SESSION : pour activer uniquement le mode débogage par étapes (step debugging)
• XDEBUG_PROFILE : pour activer uniquement le profilage des performances
• XDEBUG_TRACE : pour activer uniquement la trace d’exécution (fonctionnelle)

Ces déclencheurs permettent un contrôle plus précis de quelle fonctionnalité de Xdebug est activée, sans passer par la configuration globale des modes.

XDEBUG_SESSION_START : sessions de débogage persistantes via cookies

Si vous souhaitez déboguer plusieurs requêtes HTTP consécutives (par exemple, pour suivre un processus ou une navigation dans une application), Xdebug peut utiliser un cookie pour maintenir une session de débogage active.
Vous pouvez passer n’importe quelle valeur à XDEBUG_SESSION_START, sauf si vous avez configuré une valeur spécifique dans xdebug.trigger_value.
Fonctionne indépendamment de xdebug.start_with_request.
Cela indique à Xdebug de démarrer une session de débogage et de définir un cookie nommé XDEBUG_SESSION.

Durée de vie du Cookie : Avant Xdebug 3.1 : Le cookie avait une durée de vie par défaut
d’une heure.
À partir de Xdebug 3.1 : Le cookie n’a pas de durée d’expiration par défaut. Cela signifie
qu’il restera actif jusqu’à ce qu’il soit explicitement supprimé ou que le navigateur soit fermé
(selon le comportement du navigateur).

XDEBUG_SESSION_STOP : Arrêter une session de débogage

Pour arrêter une session de débogage et supprimer le cookie XDEBUG_SESSION, vous pouvez envoyer le paramètre suivant dans une requête HTTP (GET ou POST) :

Utiliser l’extension de navigateur Xdebug :

L’extension permet d’activer ou de désactiver le débogage en un clic, sans avoir à modifier manuellement les URL ou à ajouter des paramètres GET/POST.
Vous n’avez pas besoin de modifier chaque requête individuellement pour ajouter des paramètres comme XDEBUG_SESSION_START.

https://chromewebstore.google.com/detail/xdebug-helper-byjetbrain/aoelhdemabeimdhedkidlnbkfhnhgnhm
https://addons.mozilla.org/en-GB/firefox/addon/xdebug-helper-by-jetbrains/

Sélectionnez l’option pour activer le débogage (généralement appelée “Debug”).
Lorsque l’on active le mode Debug, l’extension injecte automatiquement un cookie nommé XDEBUG_SESSION avec une valeur spécifique (par exemple PHPSTORM ou start) dans le navigateur.

Ce cookie est envoyé avec chaque requête HTTP effectuée par le navigateur.
Lorsque le serveur reçoit une requête contenant ce cookie, Xdebug est déclenché et démarre une session de débogage.
Lorsque l’on désactive le débogage, l’extension supprime automatiquement le cookie.

Cette extension n’est pas obligatoire, elle permet simplement de se simplifier la vie en injectant directement un cookie HTTP dans le navigateur.
Comme XDEBUG_SESSION_START, le nom du cookie est important si xdebug.trigger_value est défini. Dans ce cas, la valeur du cookie doit être identique à celle définie dans trigger_value.

Note on pourrait également définir un cookies en Javascript de cette façon

Résumé des paramètres HTTP utilisés :

Utiliser une fonction Xdebug : xdebug_break() en mode Trigger :

L’appel à xdebug_break() déclenchera une connexion de débogage tant que xdebug.start_with_request est défini sur trigger et qu’aucune session de débogage n’est active.
Cela revient au même que de placer un point d’arrêt dans son IDE.
Si une session de débogage est déjà active, l’appel à xdebug_break() agira comme si un point d’arrêt avait été défini via l’IDE.

Déboguer en utilisant PHP en ligne de commande :

Si vous exécutez vos scripts PHP en ligne de commande, vous pouvez définir la variable d’environnement XDEBUG_TRIGGER.

Xdebug avec le mode Off

Rien n’est activé. Xdebug ne fait rien d’autre que vérifier si une fonctionnalité est activée.
Utilisez ce paramètre si vous souhaitez une surcharge proche de zéro.

Débogueur avec Xdebug et Docker :

Il est possible de faire fonctionner Xdebug et Docker ensemble : Xdebug sera installé dans le conteneur.

Installer Xdebug dans votre conteneur PHP :
Il faut modifier le fichier Dockerfile pour installer l’extension Xdebug directement dans le conteneur Docker.

Exemple de script pour l’installation de Xdebug en fonction de la version de PHP installée dans le conteneur (il est également possible de spécifier une version précise).

Exposer l’IP du conteneur Docker à la machine hôte :
host.docker.internal est un nom DNS spécial qui pointe vers l’IP de la machine hôte, depuis l’intérieur d’un conteneur Docker.
Il est utilisé pour permettre au conteneur de communiquer avec l’hôte (par exemple, lorsque Xdebug, dans le conteneur, doit se connecter à ton IDE sur ta machine).

Dans le cas où cela ne serait pas supporté, tu peux utiliser directement l’IP de la machine hôte.

Configurer l’IDE pour placer des points d’arrêt (ex : VSCode) :
Le chemin /var/www/html/ représente le répertoire où votre code PHP est monté dans le conteneur Docker.

Pour adapter ce chemin en fonction des projets, il faut entrer dans le conteneur et vérifier où se trouvent les fichiers de l’application web.
${workspaceFolder} est une variable de Visual Studio Code qui représente le dossier de votre espace de travail local.
Grâce à cela, Visual Studio Code sait où se trouve le code source sur votre machine locale.

Déboguer sur un serveur distant :

Déboguer un serveur distant avec Xdebug permet d’analyser et d’exécuter pas à pas un script PHP hébergé à distance, tout en utilisant un IDE local comme VS Code ou PHPStorm.
Cette méthode est essentielle pour diagnostiquer des problèmes dans des environnements ne pouvant pas exécuter d’IDE, comme les serveurs de pré-production ou de production.

Installez Xdebug sur le serveur distant, puis ajoutez ou modifiez les paramètres suivants.
Assurez-vous que le port utilisé par Xdebug (par défaut 9003 avec Xdebug 3) est ouvert sur votre pare-feu et, si besoin, redirigé sur votre routeur pour permettre la connexion entrante depuis le serveur distant.

Dans VS Code ou PHPStorm, activez l’écoute du port Xdebug (ex. : “Listen for Xdebug”).
Configurez le mapping des chemins (path mapping) entre les fichiers du serveur distant et votre projet local, afin que l’IDE reconnaisse les fichiers exécutés à distance.

Déboguer sur un serveur distant en utilisant un tunnel SSH :

Dans le fichier de configuration du serveur, configurez Xdebug pour pointer vers 127.0.0.1 (qui, via le tunnel SSH, pointera vers votre machine locale).

Créer le tunnel SSH : sur votre machine locale, ouvrez un terminal et exécutez la commande SSH.
Une fois le tunnel créé, vous pouvez placer des breakpoints dans votre IDE et exécuter des requêtes sur le serveur distant.

Le tunnel SSH doit rester actif pendant toute la session de débogage.
Le serveur distant exécute le code PHP, et Xdebug tente de se connecter à 127.0.0.1:9003 (côté serveur).
Grâce au tunnel SSH, cette connexion est redirigée vers votre machine locale sur le port 9003.
VS Code, en mode écoute, reçoit la connexion et vous permet de déboguer comme en local.

Dans le fichier /etc/ssh/sshd_config du serveur distant, assurez-vous que la redirection de port est autorisée :

Identifier une session de débogage avec xdebug.idekey (serveur partagé) :

Le paramètre xdebug.idekey est une option de configuration dans Xdebug qui permet d’identifier une session de débogage spécifique et de la relier à un IDE (comme PhpStorm, Visual Studio Code, NetBeans, etc.).
Il joue un rôle important dans la communication entre Xdebug et l’IDE. Il est essentiel pour gérer plusieurs développeurs ou IDE sur un même serveur.

Si plusieurs sessions de débogage sont déclenchées simultanément (par exemple, sur un serveur partagé), Xdebug utilise la valeur de xdebug.idekey pour s’assurer que chaque session est envoyée au bon IDE.

Configuration Réseau :

Le paramètre xdebug.client_host est utilisé par Xdebug pour se connecter à un débogueur local ou distant.
Il définit l’adresse IP ou le nom d’hôte du serveur où l’IDE (comme PhpStorm, VS Code, NetBeans) attend les connexions de débogage.

Le paramètre xdebug.client_port définit le port de connexion à l’IDE. Celui-ci est défini à 9003 par défaut.
Si ce port est utilisé par un autre service ou bloqué, vous pouvez en choisir un autre, comme 9010.
Attention : il faut également configurer l’IDE pour écouter sur ce même port.

Astuce : si vous utilisez plusieurs instances de VS Code en parallèle, vous ne pourrez pas utiliser Xdebug sur toutes en même temps avec le même port.
Dans ce cas, modifiez le port et attribuez un port différent à chaque projet (ex : 9004, 9005, 9006, etc.).

Fonction incluse avec XDebug

XDebug arrivent avec plein de fonction prete à l’emploie, qui peut etre utilisé dans les
diffèrent scripts PHP, on peut retrouver la documentation de l’ensensemble des fonctions ici
https://xdebug.org/docs/all_functions ( xdebug_info() et xdebug_break() en font partie

Voir la configuration complète d’Xdebug avec xdebug_info() :

Xdebug arrive avec de nombreuses fonctions prêtes à l’emploi, qui peuvent être utilisées dans différents scripts PHP.
Vous pouvez retrouver la documentation complète de ces fonctions ici : https://xdebug.org/docs/all_functions
(xdebug_info() et xdebug_break() en font partie).

Connaître votre version de Xdebug et les différents paramètres de configuration de Xdebug

Pour cela, vous pouvez consulter directement votre phpinfo(), qui vous donnera l’ensemble de la configuration de votre PHP, ainsi que celle de vos extensions, y compris Xdebug.

Passage à la version 3 de Xdebug :

Xdebug 3 est la dernière version majeure de l’extension Xdebug pour le débogage et le profilage.
Cependant, plusieurs changements ont été opérés lors de la mise à jour de Xdebug.

Séparation des fonctionnalités :
Dans Xdebug 2, toutes les fonctionnalités étaient regroupées dans une seule extension.
En revanche, Xdebug 3 a introduit une séparation des fonctionnalités en plusieurs composants distincts : un pour le débogage, un pour le profilage, un pour la couverture du code, etc.
Cela permet d’activer ou de désactiver les fonctionnalités individuellement, en fonction des besoins spécifiques.

La configuration des options de Xdebug 3 a été revue et simplifiée. Certaines directives de configuration ont été supprimées ou renommées afin de rendre la configuration plus claire et plus intuitive.
https://xdebug.org/docs/upgrade_guide

Cependant, pour utiliser la version 3 de Xdebug, vous devez disposer d’une version minimale de PHP.
Si vous utilisez une version trop ancienne, cela ne fonctionnera pas.
Version minimale requise pour Xdebug 3 : PHP 7.2.

Débogage : activer les logs de Xdebug :

Xdebug permet d’écrire des logs détaillés sur ses connexions. Pour les activer, ajoutez ces lignes dans votre php.ini ou xdebug.ini.

touch /var/log/xdebug.log && chmod 666 /var/log/xdebug.log

Une fois activé, Xdebug va enregistrer des informations telles que : les requêtes reçues, les tentatives de connexion à l’IDE (hôte, port, etc.), et les éventuelles erreurs (échec de connexion, IDE injoignable, etc.).
Les messages de type Critical et Error sont également enregistrés via le mécanisme de journalisation interne de PHP (configuré avec error_log dans le php.ini).

Conflit entre XDebug et l’OPCache :

OPcache (Optimized Opcode Cache) est une extension PHP conçue pour améliorer les performances des applications PHP.
Elle fonctionne en mettant en cache les opcodes (ou “code opérationnel”) des scripts PHP, ce qui permet d’éviter la recompilation des scripts à chaque exécution.

Un opcode (abréviation de “operation code”) est une représentation intermédiaire du code source PHP, générée après la phase de compilation.
Il s’agit d’un ensemble d’instructions bas niveau que le moteur Zend de PHP peut exécuter directement.

Ordre de chargement des extensions PHP :

Pour éviter les conflits et garantir un fonctionnement optimal, OPcache doit être chargé avant Xdebug.
Cela signifie que la directive zend_extension pour OPcache doit apparaître avant celle de Xdebug dans le fichier php.ini ou dans les fichiers de configuration.

Dans le dossier conf.d/, les fichiers sont chargés dans l’ordre alphabétique.
Par exemple : 10-opcache.ini sera chargé avant 20-xdebug.ini.

Voir l’ordre de chargement des fichiers de configuration avec la commande php --ini, ou dans le fichier phpinfo() à la rubrique Additional .ini files parsed.

Lorsque OPcache est activé, il met en cache les scripts PHP compilés. Si vous modifiez un fichier PHP, OPcache peut continuer à exécuter l’ancienne version mise en cache, ce qui peut poser problème lors du débogage avec Xdebug.

Si OPcache ne détecte pas les modifications du code (par exemple, si opcache.revalidate_freq est mal configuré), Xdebug pourrait déboguer une version obsolète du code.
Il s’agit de la fréquence (en secondes) à laquelle OPcache vérifie si un fichier PHP a été modifié.

Lorsque opcache.validate_timestamps est désactivé, les fichiers PHP ne sont pas périodiquement purgés par OPcache.
Dans ce cas, vous devrez réinitialiser manuellement le cache PHP.

Lorsqu’elle est activée, l’option opcache.validate_timestamps demande à OPcache de vérifier automatiquement les modifications des fichiers PHP, toutes les 15 secondes par défaut, ou toutes les opcache.revalidate_freq secondes, si ce paramètre a été modifié.

Fonctionnalités additionnelles de Xdebug (trace, profile, gcstat) :

En plus de ses fonctionnalités classiques comme le débogage à distance ou le stack trace amélioré, Xdebug propose plusieurs fonctionnalités additionnelles très utiles : trace, profile et gcstats. Passons-les en revue rapidement.

Trace – Capturer toutes les fonctions appelées avec Xdebug :

But : suivre l’exécution de chaque fonction appelée dans ton script PHP, dans l’ordre, avec :

• Le nom de la fonction
• Les arguments passés
• Le temps d’exécution de chaque fonction
• La mémoire utilisée

Utile pour :

• Comprendre le comportement de ton code
• Détecter les fonctions lentes ou inutiles
• Déboguer plus finement qu’avec un simple var_dump() ou echo

Profile – Effectuer du profilage avec Xdebug :

But : mesurer les performances globales de ton application PHP.

Génère un fichier de profil au format Cachegrind (compatible avec des outils comme KCachegrind ou Webgrind).
Enregistre :

• Le temps CPU et la mémoire utilisée pour chaque fonction
• Le nombre d’appels de chaque fonction
• Le graphe d’appel entre les fonctions (call graph)

Utile pour :

• Optimiser le code
• Identifier les goulots d’étranglement
• Suivre l’impact des changements sur les performances

En plus de Xdebug, il existe plusieurs autres outils de profilage pour PHP, chacun avec ses avantages selon le contexte.
On peut citer par exemple Blackfire ou encore XHProf.

GCStats – Statistiques du Garbage Collector :

Objectif : voir combien de cycles GC sont exécutés, combien d’objets sont nettoyés, etc.
But : diagnostiquer les performances liées au ramasse-miettes (garbage collector) de PHP
Ce que ça fait :

• Enregistre quand le GC est déclenché
• Combien de cycles il effectue
• Combien d’objets sont nettoyés
• Le temps passé dans le GC

Utile pour :

• Comprendre les problèmes de fuites de mémoire
• Optimiser les structures d’objets ou les boucles
• Vérifier si le GC s’active trop souvent (ce qui peut ralentir ton application)

Bonus : la chaîne YouTube du créateur de Xdebug :

Le créateur de l’extension Xdebug possède une chaîne YouTube, où il publie des vidéos de configuration et d’utilisation plus ou moins avancées de Xdebug :
https://www.youtube.com/@DerickRethansXdebug/videos

L’article XDEBUG – Effectuer du débogage comme un PRO est apparu en premier sur Versusmind.

De nos jours, nous utilisons un nombre colossal d’applications web à travers les réseaux sociaux, les sites de streaming ou encore certains de nos outils de travail. Pour que ces programmes existent, il est nécessaire que des personnes mettent en œuvre leurs connaissances et leurs compétences pour les créer et les faire évoluer. Il existe énormément de moyens pour créer une application web et cela peut parfois déstabiliser ceux qui veulent se lancer dans ce domaine. Je vous propose donc de parcourir quelques technologies importantes à connaître et appréciées dans le milieu informatique pour être un bon développeur web en 2023.

Les langages :

Quand on commence un projet web, la première chose à laquelle nous pensons d’un point de vue technologique, c’est sans aucun doute quels langages allons-nous choisir pour notre application ? Selon les individus, la réponse à cette question va varier en fonction de ses connaissances, ses préférences ou encore de son envie du moment. Malgré tout, nous ne pouvons pas passer outre certaines technologies et nous les retrouverons quoi qu’il arrive dans chacun de nos projets, c’est le cas de celles qui vont suivre.

1. HTML et CSS

Si vous demandez à un développeur le premier projet qu’il a réalisé en web, il y a de très fortes chances que la réponse soit un site internet statique en HTML et CSS. Ces deux langages constituent l’essence primaire d’une application web. Bien évidemment, avec ces deux seules technologies, vous n’allez pas développer des outils qui vont révolutionner l’usage que nous avons d’Internet. Cependant, leur maîtrise est nécessaire afin de pouvoir produire de bonne applications web. Un développeur qui va connaître en profondeur ces deux outils, aura la possibilité de s’affranchir des éventuels obstacles auxquels il sera confronté. Si vous souhaitez savoir si un développeur web maîtrise à minima ces deux langages, demandez-lui s’il sait centrer un élément dans une balise HTML div. Ce n’est pas très complexe, mais c’est un problème que, nous développeurs, nous avons tous déjà rencontré.  

1.2 – JavaScript et TypeScript

Avoir du contenu, c’est une chose, mais le rendre dynamique et gérer les interactions avec les utilisateurs en est une autre. Le JavaScript est le langage qui va vous permettre de donner vie à vos applications. Il offre la possibilité de manipuler votre contenu, de capturer certaines actions de l’utilisateur et d’intégrer de la logique dans vos outils. Javascript fait partie des langages les plus populaires, et ce, depuis plus de 10 ans. Très simple à apprendre avec des possibilités quasi-infinies, cette technologie vous permettra d’ajouter de nombreuses fonctionnalités à vos applications.

Pour certaines personnes, ce langage est un véritable cauchemar, car pour la petite histoire, le cœur du langage a été créé en deux semaines ce qui peut parfois provoquer quelques surprises lorsqu’on l’utilise. Heureusement, il a bien évolué et beaucoup de ses défauts ont été corrigés, mais plusieurs de ses fondements, ne pouvant pas être changés, irritent certains développeurs. Pour répondre à cette problématique, le langage TypeScript a été créé. Cette technologie est en réalité une couche au-dessus du JavaScript qui permet tout simplement d’éviter de faire n’importe quoi avec ce langage (car oui, on peut faire un peu ce qu’on veut avec du JavaScript). Il permet de mieux cadrer le développement des fonctionnalités et de rendre plus fiable l’application sur le long terme.

Au-delà des points précédents, le JavaScript possède une particularité que les autres langages web n’ont pas. En règle générale, les applications sont segmentées en deux parties distinctes, d’un côté le Front Office contenant tout l’aspect visuel et l’interaction avec l’utilisateur, de l’autre côté le Back Office avec la logique métier et tout le fonctionnement en arrière-plan. Le JavaScript permet de créer et de gérer ces deux aspects alors que la majorité des langages ne s’en occupent que d’un seul.

1.3 – Php

Le Php est une solution, qui parmi beaucoup d’autres technologies, permet de construire le Back Office d’une application web. Aujourd’hui, PHP est très présent sur le marché et bien que le langage connaisse une faible tendance baissière, le fait que 77% des Back Offices utilisent cette technologie peut nous laisser penser que cette technologie sera présente encore un bon nombre d’années. Avec cette position très forte sur le marché, les offres d’emploi nécessitant de connaître ce langage sont très nombreuses. Connaître ce langage augmente drastiquement votre employabilité dans le domaine du développement web.

Apprendre le PHP est très formateur, il est très accessible et possède des caractéristiques techniques très riches. De plus, le langage connaît des mises à jour constantes ayant pour objectif de corriger les défauts qui lui ont fait tort au fil des années. On retrouvera par exemple la possibilité de typer des variables avec PHP 7 et le pattern matching avec PHP 8. Chaque version pousse le curseur toujours plus loin pour être plus performant et pour gommer ses défauts.

Les Frameworks

Connaître les langages, c’est bien, mais dans la majorité des projets d’envergure, c’est très souvent insuffisant. Les applications web deviennent de plus en plus complexes avec davantage de fonctionnalités. 9 fois sur 10 un Framework, qui n’est qu’autre qu’une grande boîte à outils, sera utilisé pour faciliter le développement.

1. Framework JS

Depuis maintenant quelques années, les Frameworks JavaScript tels que React, Vue.JS ou encore Angular deviennent de plus en plus populaires. Ces technologies apportent une manière totalement différente de développer le Front Office dans une application. L’idée générale derrière ces Frameworks est de découper les différents éléments d’interfaces au sein de composants réutilisables. Par exemple, il est possible de créer un composant décrivant un élément simple tel qu’un bouton ou une zone de texte. En allant plus loin, il est possible de définir des composants plus complexes.

Chaque composant contient son propre code HTML, CSS, JS et peut également utiliser d’autres composants. De plus, l’une des grandes forces des Frameworks JS est de pouvoir aisément mettre en place une architecture Modèle Vue Contrôleur (MVC), qui aujourd’hui est très appréciée dans le monde du développement.

2. Laravel ou Symfony

Tout comme le JavaScript, il existe des Frameworks pour le PHP. Actuellement, les deux principales solutions utilisées sur le marché sont Laravel et Symfony avec un tiers des projets utilisant l’un de ces deux outils. Il en existe beaucoup d’autres, mais connaître l’une de ces deux technologies va permettre à un développeur de comprendre les concepts majeurs que l’on retrouve dans les différents Frameworks Back Office.

Symfony et Laravel contiennent une grande quantité de fonctionnalités permettant de développer plus vite et avec plus de fiabilité en évitant de réinventer la roue chaque semaine. De plus, étant très utilisé, il existe bon nombre de forums et de communautés pouvant aider les néophytes dans leur phase d’apprentissage de ces technologies. Les deux solutions sont en permanente évolution et suivent les différentes avancées techniques que l’on rencontre ces dernières années.

Apprendre un Framework PHP permet surtout d’avoir un code plus simple à maintenir, plus modulable, et plus lisible pour les autres collaborateurs. Toutefois attention à ne pas les utiliser n’importe comment, ce sont des solutions très lourdes et si elles sont mal utilisées, cela peut causer de gros problèmes de performance. Leur apprentissage est un long chemin à parcourir afin de pouvoir les exploiter à pleine puissance.

Les outils :

Maintenant que nous avons passé en revue les technologies à maitriser pour coder une application web, on peut se demander si cela est suffisant pour développer efficacement. Bien évidemment, il reste toujours des outils à connaître pour travailler dans de meilleures conditions.

1. Git

Réaliser du développement web veut souvent dire travailler en équipe et avoir plusieurs collaborateurs sur le même projet impose de devoir gérer les versions du code. Pour répondre à ce besoin, il existe différents gestionnaires de versions comme Github, GitLab ou encore Bitbucket qui sont tous les trois basés sur la technologie Git. Cet outil, une fois maîtrisé, va permettre à un développeur web de manipuler les versions de son code et celles de ses collaborateurs à la volée. Cette technologie est une véritable machine à voyager dans le temps pour une application quelle qu’elle soit.

Git est indispensable pour le travail en équipe, mais c’est également très puissant de manière individuelle. Parmi les nombreux usages que peut avoir l’outil, il va permettre à un développeur de sauvegarder son travail de manière journalière et ainsi éviter de perdre un ou plusieurs jours de travail (ce qui est très frustrant quand cela se produit). De plus, nous avons tous déjà rencontré un moment durant lequel nous avons réalisé qu’une de nos modifications avait cassé une autre fonctionnalité. Si l’outil GIT est bien utilisé, c’est très simple de revenir en arrière et d’identifier la cause du problème.

2. Docker

Installer et déployer un projet sur un serveur ou un poste de travail sont deux procédures qui prennent du temps et peuvent parfois s’avérer complexes. Lors du développement d’une application web, il est très fréquent d’utiliser des librairies, des Frameworks ou d’autres applications. Tout cela forme des dépendances vers l’extérieur qui elles-mêmes évoluent au cours du temps. Gérer cet écosystème est fastidieux et peut engendrer beaucoup de complexité. De plus, chaque ordinateur possède son installation ce qui peut complexifier davantage l’installation d’un projet.

Pour éviter les « cela fonctionne sur ma machine, mais pas sur une autre », il existe une solution très pratique nommée la conteneurisation. Ce sujet pourrait faire l’objet d’un article complet, pour ceux qui sont intéressés par ce sujet en détail, je vous invite à lire l’article suivant : https://versusmind.eu/blog/les-benefices-de-docker. Docker est une solution qui exploite le principe de conteneurisation, cela permet de créer des environnements complets pour une application à partir d’un script et de quelques commandes. L’énorme avantage avec cette solution, c’est qu’une fois qu’un conteneur est configuré, il peut être déployé sur n’importe quelle machine et l’application fonctionnera.

L’utilisation de docker permet également de faciliter le développement des applications au jour le jour. Il est possible de créer des commandes donnant la possibilité à un développeur de réaliser différentes actions telles que lancer des tests, installer ou déployer un projet sur un serveur distant et bien d’autres encore.

3. SonarQube

Souvent être un bon développeur signifie écrire un bon code, ce qui n’est pas toujours évident. SonarQube est un outil qui permet d’analyser un projet en profondeur afin de mettre en avant des statistiques et des alertes. Par exemple, comme vous pouvez le voir sur l’image présentée ci-dessous, différentes valeurs sont remontées par l’analyse de SonarQube. Ces informations permettent de mettre en évidence les dysfonctionnements (bugs) et les failles de sécurité (vulnérabilités) du projet. Une autre valeur transmise par l’outil est la notion de « code smells », qui permet de mettre en lumière des « petites » erreurs dans le code qui pourraient devenir des bugs dans le futur.

Exemple de dashboard SonarQube

Pour finir, développer une application web peut être très simple comme très complexe, cela va dépendre principalement des fonctionnalités qui y sont intégrées ainsi que les choix faits par l’équipe qui travaille sur le sujet. Les langages, Frameworks et outils que je vous ai présenté ne seront pas systématiquement présents dans tous les projets, mais ils forment un tout qui permet de répondre en grande majorité aux besoins d’une application web. Les connaître et les maîtriser offre une base riche et solide pour se lancer dans ce monde très vaste qui évolue à une vitesse phénoménale ! Il est crucial de rester attentif et curieux aux nouveautés que l’on peut régulièrement voir arriver sur le marché, cela permet d’observer les tendances mais également de renforcer les connaissances déjà acquises.

 

Maintenant, c’est à vous de voyager ! 

Vincent CHOQUERT

Consultant Versusmind

L’article Quelles sont les technologies à connaître et à maîtriser en 2023 pour devenir développeur web ? est apparu en premier sur Versusmind.

(source : medium.com / made by : Simplify Complexity)

Cet article vous demandera environ 20 minutes pour sa lecture complète.

Nous y dépeindrons le langage de programmation GO en commençant par les raisons de sa création, son utilité et pourquoi vous devez commencer à vous en servir.

Vous êtes prêt ? Alors Let’s GO !

Introduction

GO aussi appelé Golang est un langage de programmation open source, compilé et typé développé par Google. On doit sa création à Rob Pike, KenThompson et Robert Griesemer qui publièrent la première version le 10 novembre 2009.

Mais pourquoi avoir créé ce langage, quelles étaient les motivations de ses créateurs ?

La naissance de GO

Golang a été pensé de manière à faire face à deux grandes lois qui régissent l’évolution de la puissance de nos machines.

La première est la loi de Moore, cette loi énoncée par Gordon Moore en 1965 prédit que le nombre de transistors sur nos circuits intégrés doublera chaque année. 10 ans plus tard, il l’ajusta à deux ans au lieu d’un. Cette deuxième prédiction fut vérifiée jusqu’à 2012.

Plusieurs entreprises ont anticipé le ralentissement de cette règle et ont donc réfléchi à comment pallier ce problème, c’est alors que le processeur multi-core est né et depuis le nombre de core ne fait qu’augmenter.

C’est ainsi que la seconde loi prit le relais, la loi d’Amdhal décrite par l’informaticien Gene Amdhal en 1967. Elle prédit l’accélération théorique lors de l’utilisation de plusieurs processeurs.

Dans des termes plus simples, le temps d’exécution pourra être réduit si les programmes peuvent paralléliser au maximum leurs tâches (en utilisant tous les cores des processeurs).

C’est donc avec ces problématiques en tête et l’arrivée du cloud computing que Rob Pike, Ken Thompson et Robert Griesemer ont travaillé ensemble pour développer un langage moderne avec beaucoup d’avantages

 

Les avantages

I. Apprentissage et intelligibilités

Pourquoi ai-je qualifié GO d’ennuyeux ?

Et bien contrairement à une regex incompréhensible qui récompense votre  cerveau  avec  de  la  dopamine  lorsque  vous  la  décryptez,  le  langage  GO est clair, lisible et facilement intelligible, donc ennuyeux.

GO est proche du C, mais il possède des avantages supplémentaires comme  un  ramasse-miettes  (garbage  collector),  du  typage  structurel  et  de  la concurrence de type CSP (Communicating Sequential Processes)

 

II. Performance

1. Concurrence CSP

La majorité des langages que l’on connaît (Java, C#, Python, etc.) implémente le multithreading pour faire face aux deux lois évoquées précédemment. Mais cela leur cause des ralentissements.

Une attention particulière a donc été accordée au soutien de la concurrence, en développant des «goroutines» par opposition aux threads. Ces «goroutines» sont des fonctions qui s’exécutent en même temps que d’autres fonctions, elles peuvent être considérées comme des threads légers.

Au lieu de verrouiller les variables pour se partager la mémoire, les «goroutines» se communiquent entre elles la valeur des variables.

Leur coût de création est infime comparé à celui d’un thread. Il est donc courant que des milliers de «goroutines» soient exécutées simultanément dans une application.

2. Compilation

GO est compilé en langage machine, ce qui le rendra naturellement plus performant que les langages interprétés.

Non seulement l’exécutable qui en résulte est compilé très rapidement, mais le binaire finit par être étonnamment petit.

Par exemple le temps de compilation des 1,8 millions de lignes de code pour le projet Kubernetes v1.20.2 peuvent être compilés en 45 secondes avec un MacBook Pro de 2019 ayant un intel core i9 avec 8 core cadencés à 2,4Ghz et 32Go de RAM.

III. Cross-platform

Le langage permet la compilation pour différents langages machines et architectures de processeur (amd64, arm, etc.). De ce fait, les programmes GO peuvent  être  exécutés  sous  les  environnements  Linux,  Mac  OS,  Windows, Android même Web avec l’utilisation de Web Assembly.

 

IV. Stabilité linguistique

Il a été défini par le projet Golang que toute application codée en version 1 reste compatible, c’est-à-dire qu’une application codée en GO 1.0.0 peut être compilée en GO 1.18.2 sans soucis.

Ceci représente un réel avantage car bon nombre de langages empêche la rétro-compatibilité après une montée de version.

Les inconvénients

I. Jeunesse

Avec maintenant un peu plus de 12 ans d’existence, le langage n’a pas forcément  la  maturité  et  l’expérience  que  beaucoup  d’autres  langages  plus anciens possèdent.

La bibliothèque native de Golang est intelligemment conçue et efficace, mais  elle  est  en  concurrence  avec  des  langages  comme  Java  qui  sont soutenus par une énorme collection de code intégré maintenu et amélioré par une communauté enthousiaste et engagée.

 

II. Gestion des erreurs

Dans GO, les erreurs sont tout simplement des valeurs. De ce fait, beaucoup de fonctions finissent par renvoyer une erreur.

Cela peut causer des problèmes lorsque la source de l’erreur est perdue, ce qui entraîne une absence de logique utile pour déboguer.

 

III. Sécurité d’exécution

Par rapport à de nombreux langages de programmation, Golang est relativement  sûr,  mais  il  est  loin  d’offrir  le  niveau  de  sécurité  qu’offrent  des langages comme Rust.

Cependant, cette faiblesse n’existe que lors de la compilation et, dans une certaine mesure, de l’exécution.

 

IV. Pas de bibliothèque graphique

Golang ne dispose malheureusement pas de bibliothèque d’interface graphique,  ce  qui  signifie  que  l’on  doit  connecter  une  bibliothèque  au  lieu d’utiliser des solutions natives disponibles dans des langages tels que Python ou Java.

Intérêts d’apprendre GO

Popularité et emploi

Pourquoi apprendre à développer en GO et qu’est-ce qu’on peut développer avec ?

Actuellement, le GO est en pleine expansion sur le marché du travail. Différentes   entreprise   de   toute   taille   recherchent   des   développeurs   qui affectionnent ce langage.

On peut remarquer cette expansion avec les tableaux de popularité des langages ci-dessous :

Index TIOBE (https://www.tiobe.com/tiobe-index/)

Popularité des langages sur GitHub (https://madnight.github.io/githut/)

Utilisation

GO est de par nature multiplatform, il peut donc être utilisé pour une multitude de choses.Nous verrons ci-dessous 3 différentes utilisations de celui-ci.

 

Développement d’outils pour le Cloud

Le logiciel Docker est une technologie de conteneurisation qui permet la création et l’utilisation de conteneurs.

Il est très vite devenu la référence après sa sortie en 2013.

 

Développement d’outils CLI

Terraform est un outil logiciel open source d’infrastructure en tant que code (IaaS) créé par HashiCorp. Les utilisateurs définissent et fournissent l’infrastructure à l’aide d’un langage de configuration déclaratif spécifique à la société (HashiCorp), ou en option, JSON

 

Développement de jeux vidéo

https://ebiten.org/

Cette librairie externe permet de développer des  petits jeux vidéo cross-platform en Go.

En suivant le lien, vous pourrez trouver des exemples comme 2048, Flappy Bird, etc.

Exemple de projets

GO étant créé avec les problématiques du cloud computing en tête, ce dernier est donc l’un des plus utilisé pour développer ces outils. En voici une liste non exhaustive :

Kubernetes est un système open source qui vise à orchestrer l’automatisation et la montée en charge de conteneurs d’application sur des clusters de serveurs ».

Consul est un service mesh, il permet de découvrir et sécurisé des services au sein d’un cloud. Il est souvent utilisé dans les architectures micro-services.

Prometheus est un outil open source permettant de tracer et stocker des mesures sous forme de données chronologiques pour mieux comprendre les différentes interactions de notre architecture cloud.

CockroachDB est une base de données relationnelle SQL horizontalement scalable qui incorpore un mode de réparation automatique la rendant résiliente.

Traefik est un routeur Edge open source. Il reçoit les demandes provenant des utilisateurs ou de vos services et les redirige aux responsables de leur traitement.

À savoir qu’il peut communiquer avec le daemon Docker pour automatiser l’accès à vos services.

Comment bien démarrer ?

– https://go.dev/learn/

– https://go.dev/play/

Vos premiers programmes en GO

HelloWorld ! 

Pour votre premier programme, vous devrez tout d’abord installer GO pour ce faire, rendez-vous sur cette url : https://go.dev/dl/

Une fois installer, vous pouvez créer un dossier nommé « helloworld » 

 

Dans ce dernier, créez un fichier « main.go » ayant comme contenu les lignes suivantes :

Pour l’exécuter, démarrez un terminal dans le dossier créé précédemment nommé « helloworld » et tapez « go run main.go » 

 

Voilà ! Vous venez de faire votre premier programme en GO, simple non !?

 

Peut-être trop simple pour vous alors voyons comment on fait une API !

 

Une API HelloWorld !

Comment allons-nous faire pour développer notre API ?

 

Devons-nous importer une librairie externe pour pouvoir en développer une 

facilement ?

 

La réponse est oui et non, cela va dépendre de vos besoins, si vous souhaitez développer une grosse API résiliente, il est préférable d’utiliser des dépendances externes comme celles-ci dessous :

– Revel

– Gin

– Gorilla

– Et bien d’autres…

 

Mais vous allez voir que développer une API est extrêmement simple même 

sans utiliser une librairie externe !

 

Commençons par créer un dossier nommé « myAPI » 

Dans ce dernier, créez un fichier « main.go » ayant comme contenu les lignes suivantes :

Voilà ! En seulement quelques lignes de code intelligible vous venez de faire une API qui renvoie « HelloWorld !! » au format JSON.

Comment faire plus simple ?

Vous remarquerez que j’ai mis des commentaires mais même sans, vous auriez compris au moins dans les grandes lignes ce que fait chaque bloc.

Vous êtes convaincu et voulez en découvrir plus sur les librairies, logiciels en GO ?

Vous pouvez vous rendre sur les liens suivants :

 Go – https://pkg.go.dev/

 Github –  https://github.com/search?l=Go&q=go&type=Repositories

 Reddit – https://www.reddit.com/r/golang/

Bibliographie

Livres

Cloud Native GO. (2021). Building Reliable Services In Unreliable Environments. (1er éd). O’Reilly

Concurrency in GO. (2017). Tools & Techniques For Developers. (1er éd). O’Reilly

Learning GO. (2021). An Idiomatic Approach to Real-World Go Programming. (1er éd). O’Reilly

 

Sites

CockroachDB – https://www.cockroachlabs.com/

Docker – https://www.docker.com/

Ebiten – https://ebiten.org/

Github – https://github.com/golang/go

Hashicorp : Consul – https://www.consul.io/

Terraform – https://www.terraform.io/

Kubernetes – https://kubernetes.io/fr/

Pixelstech – https://www.pixelstech.net/article/1541901293-Advantages-anddisadvantages-of-GoLang

Prometheus – https://prometheus.io/

Medium – https://medium.com/@bluehive/how-to-check-nil-interface-ingolang-5a78a441bde2

Mobiskill – https://mobiskill.fr/blog/conseils-emploi-tech/quest-ce-que-legolang-et-pourquoi-lutiliser/

TIOBE – https://www.tiobe.com/tiobe-index/

Traefik – https://traefik.io/

Wikipédia :

CSP – https://fr.wikipedia.org/wiki/Communicating_sequential_processes

GO – https://fr.wikipedia.org/wiki/Go_(langage)

Loi d’Amdahl – https://fr.wikipedia.org/wiki/Loi_d%27Amdahl

Loi de Moore – https://fr.wikipedia.org/wiki/Loi_de_Moore

Médéric Bazart

Consultant Versusmind

L’article GO, un langage performant et ennuyant… est apparu en premier sur Versusmind.

Premiers pas sur les variables

Avant toute chose, pour que votre code fonctionne sur https://play.rust-lang.org, il va falloir l’enroller dans une fonction main. La fonction main est comme en C, c’est la fonction principale et le point d’entrée. Sur un exécutable Rust elle est obligatoire (par contre, une librairie n’en contiendra pas) .

// make variables_un

fn main() {

let x; // On peut déclarer une variable “x” sans rien lui assigner (un peu comme en C).

x = 42; // On attribue à notre variable une valeur après coup.

}

Mais au final, on fera bien plus souvent :

// make variables_deux

fn main() {

let x = 42;

}

Dans notre cas, le compilateur a attribué à la variable x automatiquement un type (i32 = entier signé de 32 bits). C’est le principe de l’inférence de type.

Néanmoins, imaginons que dans notre code, nous savons pertinemment que notre variable n’aura pas besoin d’être convertie dans un format standard.

Par conséquent, il est inutile d’avoir un entier signé et encore moins occupant une taille aussi grande. On peut donc la forcer à être la plus petite possible soit u8 (entier non signé sur 8 bits) et donc occuper 4 fois moins de place en mémoire :

// make variables_trois

fn main() {

let x:u8 = 42;

}

ou

// make variables_quatre

fn main() {

let x = 42u8; // Je suis moins fan mais les goûts et les couleurs…

}

 

Pour avoir une bonne visibilité sur les types primitifs (à apprendre par coeur), je vous invites à lire : https://doc.rust-lang.org/std/index.html#primitives

En Rust, les variables sont des constantes par défaut donc :

// make variables_cinq

fn main() {

let x = 42;

x = 50; // Renvoie une erreur de compilation.

}

Si on veut que cette variable soit mutable, on doit le préciser explicitement :

// make variables_six

fn main() {

let mut x = 42; // On initialise x à la valeur 42.

// …

x = 50; // On change la valeur de x pour qu’elle vaille désormais 50.

}

“Struct” et “enum”

Les données primitives c’est bien, mais on est vite limité. En Rust, pas de programmation orientée objet. En effet, on sépare 2 principes bien distincts : les données et les fonctions. En utilisant Rust, vous pouvez donc très bien architecturer votre code pour avoir dans des fichiers différents :

• Les structures de données : on va dire équivalentes à des classes sans méthodes.

• Les données en elle-même : si elles ne sont pas dynamiques (flux d’une api, issues d’une base de données etc) bien évidemment.

• Les algorithmes : la manière dont sont exploitées ces données.

Pour construire des données complexes, on a à notre disposition principalement les enum et les struct.

Les “struct”

C’est la donnée dans sa forme la plus pure. Elle a un gabarit qui va définir la topologie d’une donnée. Les données créées à partir des struct (instanciées dans le jargon POO) suivront cette nomenclature.

Exemple : https://github.com/mothsART/tutoRust/blob/main/src/bin/struct.rs (make struct)

Dans notre exemple, on a utilisé des primitives pour les propriétés de notre structure mais il est tout à fait possible de le composer à partir d’autres structures voir même de lui-même. Ceci sous-entend que l’on peut utiliser des structures récursives du genre :

https://github.com/mothsART/tutoRust/blob/main/src/bin/struct_recursif.rs (make struct_recursif)

 

Pour des raisons de simplification, un dossier ne peut avoir qu’un sous-dossier mais il vous serait tout à fait possible de prendre en compte une liste. Une fois avoir abordé la section “tableau”, vous serez dans la capacité de faire cela. (à bon entendeur)

 

En attendant, j’ai introduit 2 notions : Option et Box.

Rust étant centré sur la mémoire, il ne compile rien sans connaître à l’avance la taille d’une donnée. Le compilateur ne pouvant définir à l’avance la profondeur sur des données récursives, on se retrouve coincé. C’est à ce moment que Box intervient.

Sans rentrer dans les détails. Box est un pointeur sur le tas permettant d’allouer un espace mémoire dynamique. Option est un enum prenant 2 valeurs : soit Some soit None. En Rust, aucune valeur ne peut être nullable. Il faut donc encapsuler une valeur avec un Option pour permettre cela.

Dans notre cas, sans Option, notre hiérarchie a une profondeur infinie : ce qui n’est pas possible dans un contexte fini. Rust ne compile donc pas. En ajoutant un Option, on arrête donc la hiérarchie au dernier sous-dossier en lui passant None.

Les enum

Comme mentionné pour Option (qui est natif), on peut utiliser des enum.

À la différence de la plupart des langages, les enum vont être capables de lister des valeurs simples dans l’ordre (une liste d’entiers par exemple) mais également d’utiliser des structs (et inversement), d’autres enum ou encore d’utiliser de la récursivité. C’est à ce moment que vous commencez à vous rendre compte que Rust, malgré le fait qu’il n’utilise pas de POO, n’a vraiment pas à pâlir.

Un exemple vaut mieux que mille discours. Imaginez que vous développiez le module de paiement de votre banque. Vous avez plusieurs modes de paiement à votre disposition avec chacun leurs caractéristiques.

https://github.com/mothsART/tutoRust/blob/main/src/bin/enum.rs (make enum)

 

Je vous laisse apprécier l’élégance produite : dans d’autres langages, on aurait eu le droit à plusieurs if qui parasitent la compréhension (des instructions normalement réservées pour des algorithmes se retrouvent à structurer de la donnée dans plein de langages et c’est pas vraiment adéquat) et qui posent pas mal de pièges à l’exécution.

Ici, tout est vérifié côté compilation. On ne fait que proposer un gabarit et alimenter notre programme avec des données qui respectent ce gabarit. Un constat à mi-chemin sur Rust : bien structurer ces données fait parti de l’ADN du langage et si on peut passer pas mal de temps sur cette partie, c’est pour notre bien.

Pour la petite subtilité syntaxique : on accède à des propriétés d’une donnée via un “.” (ex: MaStruct.ma_propriete) et “::” quand on accède à des espaces de noms. Les enums utilisent des espaces de noms donc MonEnum::maValeur

L’ownership et la durée de vie

En Rust, une variable ne vit que dans un espace donné.

Par exemple, une variable déclarée dans une fonction ne vivra qu’au sein de cette fonction. En dehors, elle disparaîtra. Ce fonctionnement présente de vrais avantages : on limite les effets de bord et on rend chaque fonction totalement isolée du reste du programme. L’inconvénient est de transiter une donnée d’une fonction à une autre.

Vous pouvez bien évidemment cloner cette donnée mais cela signifie que l’on va la dupliquer en mémoire. Du coup, on utilise une référence (ou pointeur dans la terminologie C/C++). Tout comme l’on va se communiquer une adresse web pour parler d’un article qui nous tient à cœur, on communiquera la référence d’une donnée plutôt que la donnée elle-même.

Exemple : https://github.com/mothsART/tutoRust/blob/main/src/bin/ownership.rs (make ownership)

 

Dans notre exemple, on commence à rentrer dans le vif du sujet (enfin un peu d’algo). On déclare une struct nommée Adresse, on l’alimente avec une nouvelle donnée et on souhaite vérifier qu’elle est valide (avant enregistrement par exemple).

Vous pouvez remarquer qu’on utilise 2 formats de représentations d’une chaîne de caractères : &’static str et String. Pour faire simple, &’static str est une représentation dans son plus simple appareil ! Une adresse et une longueur (attention, longueur en mémoire ne veut pas dire longueur de la chaîne).

Elle est tout à fait suffisante dans plein de cas mais ici nous souhaitons connaître la taille de notre chaîne et ce genre d’opération n’est pas possible.

Pour tout ce qui est manipulation, vous utiliserez String (et il est aisé de passer d’un format à l’autre). Afin d’effectuer le test de vérification, on a créé une fonction qui renvoie true ou false.

Jusque là, rien de compliqué. Seulement voilà : comme dit précédemment, on déplace une donnée d’un emplacement à un autre et si on ne veut pas bêtement copier cette donnée, on est obligé de le passer par référence. C’est là qu’intervient le & qui précise que l’on ne désire pas communiquer la valeur en question mais bien un pointeur sur celle-ci.

Je vous invite à tester sans le &, le compilateur vous dira que la structure Adresse n’implémente pas le trait Copy.

Si vous remplacez #[derive(Debug)] par #[derive(Debug, Copy)], cela résoudra votre soucis mais d’une mauvaise manières : en recopiant votre donnée dans la fonction.

Beaucoup de débutants en Rust contournent ce type de soucis ainsi. Je vous le déconseille fortement car vous ne progresserez pas (sans compter les problèmes de performances engendrés). Cloner a bien une utilité mais dans un cadre restreint : vous avez 2 objets (on parle aussi d’objet en Rust bien que l’on ne soit pas dans un contexte POO) très proches dont l’un est créé à partir de l’autre. Plutôt que de recopier bêtement chaque propriété, on clone l’objet et on ne modifie que ce qui diffère.

Les tableaux

Bien évidemment, pour interagir avec des données du monde réel, il va falloir utiliser des tableaux. Rust utilise 3 notions :

1. Les array

Ce sont des tableaux statiques avec une taille en mémoire finie.On les privilégie pour le code en dur.

Exemple :

// make array

 

fn main() {

let _array: [i32; 3] = [1, 3, 8];

// Cette boucle va afficher 1, 3, 8

for x in &_array {

print!(“{} “, x);

}

}

array ne peut pas être modifié, uniquement lu et on est obligé d’ajouter un & pour pouvoir itérer dessus. Si vous mettez la variable _array en mut, on pourra changer les valeurs mais pas sa taille. Son utilisation reste donc assez limitée.

2. Les vec

Ce sont des tableaux dynamiques donc avec une taille non déterminée à l’avance :

// make vec

 

fn main() {

let mut v: Vec<u8> = Vec::new(); // On crée un nouveau Vec rempli d’entiers non signés de 8 bits.

v.push(1);

v.push(3);

v.push(8);

println!(“{:?}”, v);

}

C’est le tableau le plus courant et le plus pratique à utiliser. Sa principale limitation est qu’il représente des données stockées dans un emplacement mémoire. Si on venait à communiquer cette donnée (la passer d’une fonction à une autre), ça nécessiterait de la copier en mémoire. Pour éviter ça, on utilise une troisième représentation : les slices.

3. Les slices

Ils vont représenter un morceau de tableau via un pointeur et une taille. Si vous créez un slice à partir d’un Vec, vous ne créerez aucune donnée en mémoire supplémentaire vu que cette slice va seulement contenir l’adresse de ce morceau de Vec.

// make slice

 

fn main() {

let v = vec![1, 2, 3, 4, 5];

let v2 = &v[2..4];

println!(“v2 = {:?}”, v2); // on affiche : 2 = [3, 4]

}

Le pattern matching

Comme dans chaque langage, les if/else sont de la partie. Cependant, en Rust j’aurais tendance à dire de les oublier. En effet, l’instruction match vous permettra de faire la même chose mais de manière bien plus élégante.

Premier exemple : https://github.com/mothsART/tutoRust/blob/main/src/bin/pattern_matching_un.rs ( make pattern_matching_un)

 

Vous allez me dire que c’est un switch (notion qui n’existe pas en Rust) et vous aurez raison sur des cas simples. En Rust, match peut être utilisé sur n’importe quelle structure de données, émettre des conditions dessus et surtout, il vous obligera à être exhaustif. Voici un exemple qui va vous donner un petit aperçu de ce que l’on peut faire :

https://github.com/mothsART/tutoRust/blob/main/src/bin/pattern_matching_deux.rs (make pattern_matching_deux)

 

On retrouve des notions vues précédemment : les structures, les références, les fonctions. J’ai rajouté une boucle for qui ne devrait pas vous poser soucis. Il existe également l’instruction while et loop pour les plus curieux d’entre vous.

map, filter et closure

Si vous avez l’habitude des langages fonctionnels, vous avez l’habitude de manipuler vos données sans une succession de if (ou des match en Rust) illisibles mais avec map, filter, reduce etc. Rust inclut bien évidemment ces primitives. Voici un exemple concret qui pourrait vous en dire davantage :

https://github.com/mothsART/tutoRust/blob/main/src/bin/map_filter_closure.rs (make map_filter_closure)

Si vous ne connaissez pas les closures (propre à plein de langages), ces dernières permettent de capturer leur environnement (toutes les variables présentent dans leur scope) et d’effectuer un traitement.

En Rust, vous trouverez les closures principalement pour faire de l’événementiel, de l’asynchronisme, des évaluations paresseuses et du traitement de données.

L’implémentation et les traits

Pour l’instant, vous avez découvert des fonctions simples. Néanmoins, on peut définir une liste de méthodes en une structure. Vous allez voir qu’au final, on est très proche de l’orienté objet mais sans rentrer dans ces travers et toujours en dissociant structures, données et calculs.

Exemple : https://github.com/mothsART/tutoRust/blob/main/src/bin/implement.rs (make implement)

Pour forcer une implémentation précise, Rust met à disposition les trait. C’est grosso modo l’équivalent des interfaces dans le monde objet.

Revoyons notre exemple avec un trait : https://github.com/mothsART/tutoRust/blob/main/src/bin/trait.rs (make trait)

Pour notre exemple, ça ne change pas grand chose mais imaginons que nous voulions avoir la même API pour des rovers pilotables sur Terre, Mars et Vénus. Leur implémentation sera très différente mais vu de l’extérieur, ils auront les mêmes fonctions !

Bien évidemment, vous pouvez implémenter une infinité de trait pour une structure. Par exemple, pour les rovers de Mars et Vénus, on pourrait avoir un trait CapteurDeTemperature qui serait probablement inutile pour celui terrestre. Le rover Persévérance pourrait implémenter le trait SpectrometreLaser inutile pour bien d’autres rovers qui n’ont pas besoin de détecter des molécules organiques etc.

Conclusion

Vous avez fait un tour d’horizon de bons nombres de fonctionnalités de Rust. Il resterait sans doute des choses à dire sur :

• La généricité
• L’asynchronisme
• Les macros
• Les types RefCell et Rc
• Les Foreign Function Interface et l’unsafe
• La documentation
• Les tests unitaires et les benchmarks
• Les espaces de noms, les projets multi-fichiers et la gestion des libs/dépendances
• L’utilisation de Cargo
• etc.

 

Néanmoins, je pense vous avoir déjà donné les premières armes pour un démarrage rapide. Le mieux étant déjà d’expérimenter et surtout en Rust, d’apprivoiser le compilateur. Ce dernier vous semblera à vos débuts votre pire ennemi mais cette tendance va s’inverser !

Je vous conseille dans la phase de prototypage :

De préfixer vos variables non utilisées avec un “_” : le compilateur n’émettra pas de warnings.

D’utiliser des unwrap() plutôt que de tout gérer parfaitement du premier coup.

Cela vous permettra d’avancer vite sans vous soucier des détails. En revanche, une fois votre structure de données maîtrisée et avant la phase de production, remplacez dûment tout ce beau monde !

Jérémie Ferry

Consultant Versusmind

L’article Rust par la pratique est apparu en premier sur Versusmind.

Rust est un langage de programmation créé à l’initiative de la Fondation Mozilla. Il résulte en réalité du projet personnel de l’employé Graydon Hoare. Son but premier était d’améliorer (voir de remplacer) le moteur de rendu du navigateur Firefox nommé Gecko.

Après des années d’usage et des millions de lignes de code en C/C++, Mozilla a dressé un constat assez amer de son outil Gecko :
● Des soucis de gestion de mémoire (fuites principalement) difficiles à anticiper et à corriger ;
● Des failles de sécurité ;
● Des besoins en programmation concurrente complexe et difficile à mettre en place.

Cherchant un langage plus adapté à ses besoins, la fondation s’est rendue compte qu’aucune solution existante ne couvrait parfaitement ses exigences. C’est ainsi qu’est né Rust.

Développé timidement dans un premier temps, Rust a connu un véritable essor en 2015 avec son passage officiel en version stable. C’est d’ailleurs à peu près à cette période que j’ai commencé à m’y intéresser sérieusement. Peu à peu, la communauté autour de Rust a grandi. Le 18 août 2020, elle est même devenue une fondation indépendante sponsorisée par de nombreuses entreprises.

Le langage Rust a été construit autour de trois objectifs : la performance, la fiabilité et la productivité. On peut dire qu’il en poursuit également un quatrième de façon officieuse : la prise en charge d’un maximum d’architectures de processeurs.

Le nom Rust, qui signifie “rouille” en anglais, peut faire sourire. En effet, l’idée est que le langage soit adapté pour des conditions réelles et ne se veut pas académique (en testant de nouveaux concepts tel que le ferait Haskell, par exemple). Il reprend donc tout ce qui se fait de mieux dans d’autres langages sans réinventer la poudre. Ainsi, Rust n’implémente que des paradigmes qui ont eu le temps de mûrir et d’être éprouvés :
● Paradigme déclaratif : logique sans état qui évite les effets de bord. Il peut s’agir, par exemple, d’une fonction appelée avec les mêmes paramètres d’entrées et qui fournira le même résultat peu importe le contexte ;
● Paradigme fonctionnel : inférence de type, lambda-calcul, récursivité, évaluations paresseuses, curryfication, filtrage par motif, closures, functeurs, monades, map/reduce/filter, etc ;
● Paradigme de généricité (ou plus précisément le Polymorphisme paramétrique) : capacité de manipuler des objets très différents du moment qu’ils implémentent les mêmes traits (un trait est en Rust l’équivalent des interfaces en POO) ;
● Paradigme de concurrence : capacité de faire des tâches en simultanées.

Quel intérêt ?

Il est vrai que je n’ai pas eu mention d’un projet en Rust au sein de Versusmind. Alors, pourquoi m’y intéresser ?

Notre secteur d’activité se réinvente perpétuellement et les “technologies stars” d’aujourd’hui sont probablement les “dinosaures” de demain. Certaines vont indéniablement sortir du lot dans les années qui viennent et pourront potentiellement intéresser les entreprises avec qui je serais amené à travailler. Rust fait partie du peloton de tête. Il suffit de regarder des statistiques sur le sujet :
● L’index TIOBE : https://www.tiobe.com/tiobe-index/
● La popularité dans les recherches Google : https://pypl.github.io/PYPL.html
● Le croisement de la popularité sur Github et stackoverflow : https://redmonk.com/sogrady/2020/07/27/language-rankings-6-20/

D’une part, je pense que c’est en s’engageant dans des expertises nouvelles, via le biais de ses consultants, qu’une entreprise comme Versusmind pourra proposer une palette de compétences plus large à ses clients.

D’autre part, je suis convaincu qu’il est opportun d’élargir son spectre de connaissances et de ne pas se limiter à la stack connue. Apprendre un autre langage informatique et, par conséquent, découvrir de nouvelles approches pour résoudre des problématiques communes permet d’affiner son expertise, sortir de son périmètre de confort et avancer. Ainsi, mon idée derrière la rédaction de cet article n’est bien évidemment pas de vous faire progressivement abandonner quoi que ce soit pour autre chose mais bien d’élargir votre cercle de connaissances.

Enfin, rien n’interdit de faire du Rust dès maintenant à titre professionnel. Comment ? Je m’explique. Que vous codiez majoritairement en PHP, .Net, Node, rien ne vous interdit d’utiliser un autre langage pour des petits projets, par exemple en réalisant des bots Discord, des hook Git, etc. Dans un second temps, cela peut vous permettre de réaliser des scripts de migration ou de petits utilitaires pour croître en productivité. Enfin, même si cela est peu recommandé, Rust peut s’interfacer avec d’autres langages grâce à une API dédiée à l’interopérabilité (https://doc.rust-lang.org/rust-by-example/std_misc/ffi.html).

Les grands atouts de Rust

1 – La performance

L’idée principale de Rust est d’être au plus proche du comportement de la machine tout en donnant le maximum d’abstraction au développeur final. Ce langage se distingue de ses homologues grâce à la performance brute qui sera toujours privilégiée à l’expérience du développeur. Ainsi, certains concepts n’existeront jamais nativement en Rust. Puisqu’il n’y a pas de “ramasse-miettes” (Garbage Collector), la responsabilité de la gestion mémoire est à la charge du développeur. Ceci implique l’impossibilité de s’abstraire de la notion de pointeur et de distinction stricte entre mémoire sur le “tas” et sur la “pile” (heap and stack).

Qui dit performance optimale dit aussi compilation et absence de machine virtuelle. Cela implique qu’un binaire Rust compilé sur une architecture cible ne fonctionnera pas vers une seconde architecture différente (par exemple, de l’ARM ne fonctionnera pas sur de l’AMD 64). Les langages interprétés ( .NET ou Java) sont quant à eux indépendants du système sur lequel les codes sources sont exécutés car ils le sont au sein de leurs propres machines virtuelles.

Les langages compilés permettent eux de faire du très bas niveau, comme la création d’un OS. D’ailleurs, Redox est un OS entièrement écrit en Rust. Linus Torvalds envisage également des contributions au Kernel Linux avec le langage Rust (dans un premier temps uniquement pour des drivers bien cloisonnés du reste du code, mais c’est historique). Microsoft, Apple et Amazon ne sont pas en reste et utilisent déjà Rust dans des projets internes. On peut difficilement miser sur un système performant sans typage fort. Cela implique que si vous choisissez mal vos types, vous n’aurez pas forcément les performances souhaitées.

Enfin, Rust permet de différencier la logique de la compilation et de l’exécution. Ainsi, on se rend compte que beaucoup de choses peuvent être définies statiquement, réglées à la compilation et que la partie réellement dynamique est souvent secondaire. Par exemple, on peut effectuer des calculs réguliers avec la racine de PI alors qu’une valeur avec 10 décimales suffit. Ainsi, pourquoi ne pas créer une constante à la compilation pour éviter de la calculer un nombre défini de fois à l’exécution ?

Une attention toute particulière a été mise sur l’asynchronisme avec les mots clés Async/Await et les notions de Future et de Stream. Dès que l’on souhaite faire de l’asynchrone pour de l’accès au disque, du TCP/UDP, le mieux est de partir sur des libs comme Tokio https://docs.rs/tokio/1.0.1/tokio/ qui vous donneront l’abstraction nécessaire pour gagner en productivité et relecture. Vous pouvez également utiliser, dans des cas plus marginaux des threads : https://blog.guillaume-gomez.fr/Rust/3/5.

2 – La fiabilité

Si vous faites ou avez déjà fait du C/C++, vous savez à quel point l’utilisation de la mémoire peut être une épée de damoclès (fuite mémoire, dépassement de tampon, etc). Rust évite la plupart de ces problèmes grâce à trois principes :
● Les variables sont, par défaut, des constantes : il faut préciser explicitement quand elles sont “mutables” ;
● L’ownership : https://blog.guillaume-gomez.fr/Rust/2/6 ;
● La durée de vie : https://blog.guillaume-gomez.fr/Rust/2/7.

 

Comme je l’ai déjà mentionné, Rust est typé fortement et ces types “primitifs” sont assez étendus :
● Nombres entiers signés/non signés de 8, 16, 32, 64 bits
● Chaîne de caractère définie et dynamique

Retrouvez d’autres types pimitifs ici : https://doc.rust-lang.org/rust-by-example/primitives.html

On note une distinction importante par rapport à plusieurs autres langages : les types nullables n’existent pas. Pour qu’une variable puisse être vide, il faut l’enroller dans un enum de type Option (https://doc.rust-lang.org/stable/std/option/enum.Option.html) qui prend deux valeurs possibles : Some (qui contient une donnée) ou None (ne contient rien). Le compilateur de Rust incite à déclarer explicitement, à chaque utilisation, les deux scénarios. En somme, définir ce qui se passe si la variable contient une donnée ou non. Ce choix dénote une problématique rencontrée par les développeurs sous C# : https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

En Rust, il n’existe pas de système d’exception (try/except/finally/throw n’existe pas). Une erreur est un type en soi et elle est tout aussi importante qu’un comportement “attendu”. L’intérêt est de responsabiliser le développeur dès le début du projet sur la notion d’erreur et quel comportement adopter dans ce cas. La nature humaine nous pousse assez naturellement à n’envisager que les scénarios dans lesquels tout se passe bien et à éviter ou reporter ceux qui ne le sont pas. Par conséquent, certains bugs n’apparaissent qu’en production et le coût de correction (et de stress) qu’ils occasionnent est rarement favorable.

Du côté Rust, traiter une erreur est tout aussi important qu’un succès et tous les scénarios doivent être anticipés pour passer la phase de compilation. Pour la plupart des développeurs, il peut être frustrant d’écrire beaucoup de code pour une “mini” fonctionnalité mais, au final, c’est bien plus reposant car on évite une paire d’oublis. Ainsi, on focalise notre matière grise sur ce qui est vraiment important.

3 – La productivité

Souvent, les avantages se recoupent : écrire du code fortement typé c’est éviter de la perte de temps sur du debuggage et, par conséquent, s’allouer un temps non négligeable sur de la fonctionnalité. Un développeur qui travaille sur un projet sérieux va forcément passer par la case “suppression de code” et se rendre compte que cela peut être bien plus difficile que d’en ajouter.

Dans ce cas de figure, deux politiques s’opposent : soit on ne supprime rien (c’est la solution souvent choisie malgré de la bonne volonté), soit on déprécie et on supprime dans un second temps. Dans ce second scénario, la recette a une importance cruciale. Néanmoins, lors de la mise en production, on croise les doigts tout en gardant les yeux rivés sur les logs.

Rust s’oriente sur un autre axe : la vérification à la compilation du code mort. Si une constante, une fonction ou une structure de donnée n’est utilisée nul part, Rust considère que c’est du code mort et le signale avec un gros warning. Il est fort plaisant de refactorer un projet que vous n’avez pas développé (ou que vous avez abandonné depuis longtemps) et ne rien oublier à la suppression dès le premier commit.

La communauté de Rust a aussi fait le choix de doter le langage d’outils fournis par défaut (battery included). L’un d’entre eux est indispensable car c’est l’utilitaire qui manage tout et qui évolue à la même vitesse que le langage. Il s’agit de Cargo, qui fait office de :
● Gestionnaire de paquets (qui d’ailleurs est couplé avec le dépôt “crate.io”). Il brille par sa qualité et sa simplicité. On édite un fichier Cargo.toml (pour ceux qui ne connaissent pas TOML, je vous invite à le découvrir car il présente de nombreux avantages par rapport à YAML, JSON et cie pour de la conf) et la magie opère.
● Librairie de tests : un simple “Cargo test” va lancer les tests unitaires et fonctionnels de votre applicatif et tout ceci sans librairie complémentaire.
● Tests de montée en charge avec “Cargo bench”
● Générateur de documentation : “Cargo doc” va sonder l’ensemble de votre API et créer une documentation correspondante (hiérarchie de docs HTML).

Cargo peut être étendu et, par conséquent, apporter des outils complémentaires.

Les inconvénients

Il serait malhonnête de ma part de vous présenter uniquement les aspects positifs de Rust. Voici une liste non-exhaustive de ses inconvénients :
● Rust nécessite une courbe d’apprentissage élevée et les débuts peuvent être laborieux. Ce n’est pas un outil magique. Il permet d’éviter les pièges mais reste dans du bas niveau.
● Les 3 objectifs que se fixe Rust ne sont pas pleinement atteints : par exemple, certaines instructions ARM ne sont pas encore supportées par le compilateur ce qui fait que le binaire produit peut être lent.
● Rust fait beaucoup de vérifications à la compilation et ceci a un coût : les temps de compilation peuvent être frustrants surtout sur de gros projets avec de la refacto. Même s’il y a eu beaucoup d’améliorations à ce sujet ces derniers temps, cela peut rester insuffisant.
● Rust n’est sans doute pas fait pour prototyper, créer du script rapide et jetable etc. Comme beaucoup d’outils, si il n’est pas utilisé à bon escient, il perd de son intérêt. Pour ma part, je jongle souvent entre Python (faire des trucs vite) et Rust (faire du durable).
● Plusieurs librairies sont des bindings de code en C, ce qui sous-entend que certaines parties (certes cloisonnées) sont unsafe. Cela peut donc potentiellement avoir des conséquences sur les trois axes fixés par Rust.
● Le compilateur n’est pas vérifié formellement ce qui sous-entend qu’il peut y avoir des bugs dans son interprétation. Des projets sont en cours dans ce sens, en particulier dans la vérification des parties “unsafe”.
● Le langage n’est pas normalisé (à la différence de C et C++ qui ont des normes ANSI et ISO) et il n’y a qu’un seul réel compilateur.
● Certains concepts fonctionnels sont encore effleurés : les notions d’évaluations paresseuses ne sont pas encore stabilisées, la notion de monade n’existe pas vraiment (mais les plus utiles comme Maybe sont implémentés).

Quelques conseils et exemples de projets réalisés en Rust

Pour trouver des projets (lib, frameworks, softs) devs en Rust, je vous invite à passer par https://github.com/rust-unofficial/awesome-rustfmt. Vous trouverez aussi votre bonheur sur https://wiki.mozilla.org/Areweyet. Ce tableau liste tous les projets “Are we … yet” et donne donc une liste des projets les plus courants pour un thème précis.

Par exemple, https://www.arewewebyet.org/ va lister tous les frameworks cool pour faire du web en Rust : Actix et Rocket sont actuellement les frameworks les plus populaires et matures. Yew est un framework pour faire du Webassembly et j’invite à le tester pour faire du front sans une once de javascript et permettant de faire de l’isomorphisme si on utilise Rust également côté serveur.

Ripgrep : https://github.com/BurntSushi/ripgrep si vous aimez grep mais que vous le trouvez un peu verbeux et surtout lent, je vous invite à installer ripgrep (aussi bien sur linux, windows ou mac). C’est le genre de petit soft dont je ne peux plus me passer.

La lib Nom : https://github.com/Geal/nom va vous permettre de parser du texte et/ou du contenu binaire. La vraie plus value vient de la partie combinatoire. Au lieu de s’appuyer sur des expressions régulières où chaque modifs peuvent avoir un effet big bang, le parser Nom se décompose en petits algos unitaires totalement indépendants les uns des autres.

● Redox : un système d’exploitation complet type Unix basé sur un microkernel.

● Deno : le successeur de NodeJS

● SWC : transpiler du Javascript bien plus vite que Babel : https://github.com/swc-project/swc

● Sonic : une alternative à ElasticSearch https://github.com/valeriansaliou/sonic

● Sozu : Un reverse proxy qui est configurable à chaud, possibilité de montée de version à chaud également, rapide et sécurisé.

● Servo : https://github.com/servo/servo un navigateur entièrement en Rust dont certaines parties ont été intégrées à Firefox.

● Zola : créé son site web statique https://github.com/getzola/zola

● Nushell : https://github.com/nushell/nushell

Voici également une liste de petits utilitaires malins tel que :

● exa https://the.exa.website à la place de ls.

● bat https://github.com/sharkdp/bat à la place de cat.

● fd https://github.com/sharkdp/fd à la place de find.

● hyperfine https://github.com/mothsART/hyperfine à la place de time.

● delta https://github.com/dandavison/delta à la place de diff.

● dust https://github.com/bootandy/dust à la place de du.

● sd https://github.com/chmln/sd à la place de sed.

Il existe même un projet de réécriture des core utils GNU en Rust : https://github.com/uutils/coreutils (qui permet un support complet sur Windows notamment).

La communauté Rust

Rust est un langage plutôt bien accueilli dans la francophonie. Vous trouverez pas mal d’articles et d’aide à son sujet.

Pour ceux qui ont du mal avec l’anglais :

● https://rust.developpez.com

● Un chan IRC : #rustfr sur le serveur chat.freenode.net

● des podcasts sur le sujet : https://www.clever-cloud.com/fr/podcast

Pour les autres, voici des liens utiles vers des communautés :

● Un forum https://users.rust-lang.org

● Un discord actif : https://discord.gg/rust-lang

● Un zulip : https://rust-lang.zulipchat.com

● Plein de réponses aux questions récurrentes sur stackoverflow

● Plein d’échanges sur Reddit

● Des projets github et gitlab à foison

Pour bien démarrer

Pour démarrer un projet Rust, je vous conseille de vous référer au site de Rust, tout simplement : https://www.rust-lang.org. Le tutoriel en français de Guillaume Gomez (un développeur Core) est aussi un bon élément pour entamer un premier projet en Rust : https://blog.guillaume-gomez.fr/Rust.

Si vous préférez commencer par un entraînement, voici des petits exercices divers et variés : https://github.com/exercism/rustfmt. Il existe également un ensemble de petits exemples de code pour une entrée en matière d’une demi-heure : https://fasterthanli.me/articles/a-half-hour-to-learn-rust.

Je me suis également référé à deux livres pour m’aider dans mon apprentissage de Rust :

● Programming Rust que j’ai dévoré https://www.abebooks.fr/products/isbn/9781491927281?cm_sp=rec-_-pd_hw_o_1-_-plp&reftag=pd_hw_o_1 et qui a désormais sa traduction https://www.amazon.fr/Programmer-avec-Rust-programmation-collection/dp/241204659X

● The Rust Programming Langage de Carols Nichols : https://www.abebooks.fr/Rust-Programming-Language-Manga-Guide-Carol/30645072052/bd?cm_mmc=ggl-_-FR_Shopp_TradeStandard-_-naa-_-naa&gclid=Cj0KCQiA88X_BRDUARIsACVMYD8o_qMPKplUEOMXeC0N5AheAzPcWqmc6pWv15xvdrOoLKogq-SMVeEaAicOEALw_wcB

La plupart des développeurs supportent au moins la coloration syntaxique de Rust mais Visual Code semble avoir le meilleur support actuellement. Voici un lien vers éditeur de texte web pour des tests rapides : https://play.rust-lang.org.

J’invite les plus combatifs d’entre vous à convertir des mini softs ou des algos d’un langage à un autre. J’ai tenté l’opération pour du C, du C++, du Python et c’est assez formateur de réécrire littéralement dans un premier temps puis de le penser avec la philosophie de Rust dans un second temps.

Voici enfin un point d’entrée intéressant (si vous ne le connaissez pas déjà) : https://rosettacode.org ou des algos avec la même finalité sont présentés dans divers langages.

Quelques outils pour aller (encore) plus loin

● rustfmt : Pour que votre code soit lisible et toujours formaté de la même façon, je vous encourage à utiliser https://github.com/rust-lang/rustfmt C’est une extension a Cargo (Cargo ffmt) qui va vous imposer une ligne directrice sur la présentation.

● clippy : un analyseur de code statique qui va vous permettre d’éviter des bugs au runtime, de simplifier du code, d’améliorer les perfs etc. Il existe également une extension Cargo appelée Cargo Clippy.

● Miri : un analyseur de code dynamique (encore expérimental) qui permet de détecter des bugs plus sournois notamment dans les parties unsafes : https://github.com/rust-lang/miri.

● Clap : https://clap.rs pour créer rapidement des utilitaires en ligne de commande.

● Diesel : un ORM en Rust http://diesel.rs.

● afl : rajouter du fuzzing dans vos projets https://github.com/rust-fuzz/afl.rs.

Jérémie Ferry

Consultant Versusmind

L’article Introduction à Rust est apparu en premier sur Versusmind.

L’article Améliorer sa boucle de développement avec Spring-Boot-DevTools est apparu en premier sur Versusmind.

Que vous soyez développeur WEB confirmé ou simplement friand d’architectures digitales modernes et puissantes, la JAMstack saura vous intéresser. Apparue il y a déjà quelques années, la JAMstack a déjà su faire ses preuves et amadouer de nombreux développeurs à l’aide de son expérience de développement à la pointe des technologies actuelles, son expérience d’édition agréable et ses performances à toute épreuve. Au cours de cet article vous découvrirez et apprendrez à mettre en place et déployer une architecture suivant les principes de la JAMstack en utilisant des outils tels que Gatsby, Netlify CMS et Azure.

Présentation de la JAMstack

Lexique

Afin de comprendre au mieux cet article, vous aurez besoin de connaître un certain nombre de termes dont voici leurs courtes définitions. Derrière chacun de ces termes se cache une technologie qui mériterait un article entier à elle seule, alors n’hésitez pas à approfondir vos recherches si le sujet vous intéresse.

1 – SSG : Static Site Generator (ou Générateur de Sites Statiques) : c’est une couche de l’architecture capable de générer des pages WEB en remplissant des templates à l’aide de données et de contenus fournis dynamiquement. Les SSGs se différent des applications WEB classiques par leur cycle de fonctionnement. Une application classique attendra une requête pour générer une page WEB lorsqu’un SSG créera à l’avance toutes les pages possibles afin d’être prêt à servir toutes les requêtes.

2 – CMS : Content Management System (ou Système de Gestion de Contenu) : c’est un système fournissant une interface d’utilisation simple permettant aux utilisateurs de réaliser des sites ou applications WEB dynamiques sans forcément connaître les technologies nécessaires au développement WEB. Elles permettent notamment de gérer le contenu du site via une interface d’administration préconstruite.
3 – CMS Headless : Il s’agit d’un CMS classique pour lequel on a retiré la gestion du site WEB. Ainsi, un CMS Headless ne s’occupera que de contenu et permettra aux utilisateurs de gérer facilement ce contenu via une interface préconstruite.
4 – API : Application Programming Interface (ou Interface de Programmation d’Application) – c’est une façade normalisée par laquelle un programme offre une partie de ses services à un autre.
5 – CDN : Content Delivery Network (ou Réseau de Livraison de Contenu) – c’est un réseau distribué de serveurs proxy associés à des serveurs de données, permettant une distribution des données selon la situation géographique de l’utilisateur ayant pour conséquence une haute disponibilité des données et d’excellentes performances.

La JAMstack dans son ensemble

Apparue en 2016 grâce à la popularité des sites statiques, la JAMstack est une architecture de développement WEB basée sur du Javascript client, des APIs réutilisables et du Markup préconstruit. Elle tient son nom d’un acronyme :

→ J pour Javascript : les fonctionnalités dynamiques sont gérées par du Javascript.

→ A pour API : toutes les opérations côté serveurs sont abstraites par des APIs réutilisables.

→ M pour Markup : le site WEB est servi via des fichiers HTML statiques construits à partir de fichiers sources comme du Markup.

Ces trois spécificités de la JAMstack vont directement impliquer des contraintes et des libertés sur l’architecture :

→ L’utilisation de fichiers HTML comme rendu final permet l’utilisation d’un CDN et donc permet d’excellentes performances, un coût réduit et une mise à l’échelle transparente.
→ L’abstraction de toutes opérations côté serveur via des APIs offre une meilleure sécurité du système.
→ L’utilisation de SSG et de CMS Headless permet une automatisation totale du workflow et donc une meilleure maintenabilité.

Analyse de l’architecture

Afin de mettre en place une architecture de JAMstack, nous aurons besoin de quatre outils :

→ Un générateur de sites statiques : Il en existe de nombreux, et pour des raisons de popularité, de maturité et de fonctionnalités, c’est Gatsby qui sera choisi ici.

→ Un CMS Headless :  ils peuvent se différencier en deux types, API-driven et Git-based. La différence étant la façon dont les données sont stockées et consommées. Un CMS Headless API-driven fonctionnera sous la forme d’une API classique dont le stockage interne du contenu sera caché de l’utilisateur mais disponibles via des requêtes Http classiques et sécurisées. Un CMS Headless Git-based stockera le contenu directement dans des fichiers qui seront hébergés avec le code source permettant au passage un versioning du contenu au même titre que celui du code source. Pour des raisons similaires au choix du SSG, c’est Netlify CMS (Git-based) qui sera choisi ici.

→ Un système de contrôle de versions : à l’heure actuelle, seul GitHub est géré par les Azure Static Web Apps (service dont nous aurons besoin plus tard), et c’est donc celui-ci qui sera choisi.

→ Un outil capable d’héberger notre générateur de sites statiques, notre CMS headless et les différentes APIs dont nous pourrions avoir besoin : ici nous choisirons Microsoft Azure.

Le fonctionnement de l’architecture se fera de la manière suivante :

1 – Gatsby récupère le contenu stocké par Netlify CMS dans des fichiers Markdown et s’en sert pour remplir des Templates afin de générer un site WEB statique et le servir via un CDN.
2 – Un éditeur accède à Netlify CMS à travers le CDN et modifie le contenu via une interface d’administration simple et intuitive. Cette modification entraîne une modification des fichiers Markdowns stockés dans le code source, et donc du code source lui-même.
3 – La modification du code source entraîne un nouveau build de la part de Gatsby et donc une modification du site WEB lui-même, le contenu est donc bien mis à jour d’après l’éditeur, le tout de manière automatisée et sécurisée.

Passage à la pratique

Nous venons d’obtenir de nombreuses informations concernant la JAMstack, il est temps de les mettre en pratique. Commençons par mettre en place les différents éléments de l’architecture à l’aide d’un starter. Gatsby propose de nombreux starters disponibles ici et celui qui va en particulier nous intéresser est celui-ci.

Commençons par le mettre en place sur GitHub

Commençons par créer un nouveau Repository depuis un compte GitHub puis par cloner ce dernier.

Assurons-nous ensuite d’avoir Node.js d’installé sur notre machine puis ouvrons un terminal de commande pour exécuter les commandes suivantes :

#installer la CLI de gatsby npm i -g gatsby-cli #créer le projet à partir du starter gatsby new web https://github.com/netlify-templates/gatsby-starter-netlify-cms #cd web #ajouter le package copyfiles qui nous servira par la suite npm i copyfiles

Afin de faire fonctionner Netlify CMS sur une Azure static web app, nous allons ensuite devoir modifier la section “scripts” du fichier /web/package.json comme suit :

“scripts”: { “clean”: “gatsby clean”, “start”: “npm run develop”, “mvFiles”: “copyfiles -f public/admin/*.js public/admin/*.css public/admin/*.yml public/”, “build”: “npm run clean && gatsby build && npm run mvFiles“,

Nous pouvons alors ajouter le dossier web au git et commit/push la mise en place du starter.

Création d’une Azure Static Web app

Rendons nous sur le portail d’Azure, un compte Microsoft sera alors nécessaire. Puis, dans la barre de recherche, entrons “static web app” afin d’en créer une. Il ne reste plus qu’à remplir le formulaire et se laisser guider par l’interface intuitive d’Azure.

 

Une fois créée, cette ressource sera connectée à notre repository GitHub et lancera une GitHub Action afin de générer un build de la part de Gatsby puis d’exporter le site statique produit sur la static web app. Une fois la GitHub Action terminée, vous pourrez alors retrouver le starter déployé en explorant l’URL fournie par Azure.

Analyse du projet

La structure du dossier est telle quelle :

web

|- public/   (c’est là que le site web statique sera généré)

|- static/   (il s’agit des fichiers non traités par gatsby)

|- src/   (les fichiers permettant de générer le site final)

|- gatsby-config.js       (il s’agit d’un fichier spécial pour Gatsby)

|- gatsby-node.js         (il s’agit aussi d’un fichier spécial pour Gatsby)

 

Les fichiers gatsby-config.js et gatsby-node.js sont des fichiers permettant de configurer certaines actions de Gatsby mais nous n’en parlerons pas ici. Dans le cas présent, elles vont permettre d’indiquer à Gatsby qu’il faut traiter les fichiers Markdown utilisés par Netlify CMS, mais heureusement, la mise en place du starter l’a déjà faite pour nous, il n’est donc pas nécessaire d’y toucher pour l’instant.

 

Le dossier public ne sera modifié que par Gatsby directement, puis envoyé tel quel au CDN, il n’est donc pas nécessaire non plus d’y toucher ou de s’y intéresser.

 

Le dossier src va contenir toutes les informations dont gatsby a besoin pour générer un site web statique, soit dans le cas présent :
→ des composants React afin de découper la structure des pages web en composants testables et réutilisables
→ des dossiers comme img permettant de stocker les assets de notre solution
→ un dossier pages contenant des  fichiers js permettant de définir la structure des pages. Par défaut, Gatsby va utiliser la structure de ce dossier pour générer la structure du site web. Ainsi si l’on crée un dossier pages/test et que l’on y met un fichier js décrivant une page web, Gatsby va générer cette page dans le dossier public/test/index.html et elle sera donc servie sur l’url ‘…/test’ une fois le site web déployé sur CDN.
→ un dossier templates contenant des templates React qui vont eux même être associés à des fichiers .md qui sont stockés dans le dossier pages et gérés par Netlify CMS, permettant de générer des pages qui pourront être modifiées directement via l’interface d’administration fournie par ce dernier.

Lancement du projet et développement local

Afin de rendre Netlify CMS disponible, nous allons devoir au préalable modifier son fichier de config, rendons nous dans le dossier static/admin et modifions le fichier config.yml comme suit :

 

backend: name: github repo:# Path to your GitHub repository branch: master commit_messages: …

Reprenons un terminal dans le dossier web et lançons la commande suivante :

 

npm start

Notre site web est maintenant déployé en local et nous pouvons y accéder via l’url ‘localhost:8000’, nous y trouverons alors le starter que nous avons mis en place. Nous pourrons alors modifier notre projet gatsby et y observer les modifications en temps réel.

 

Nous retrouverons ensuite l’interface d’administration de Netlify CMS présente à l’adresse ‘localhost:8000/admin’ qui nous demandera alors de nous connecter avec notre compte github. Nous serons ensuite redirigé vers l’interface simple et intuitive de  Netlify CMS nous permettant de gérer le contenu de notre site WEB.

 

Essayons de modifier l’une des collections déjà présentes et de publier cette modification. Nous verrons alors un nouveau commit sur la branche master de notre git générant un nouveau build via une github action mise en place par notre Azure Static web app. Au bout de quelques minutes, notre site web sera alors à nouveau déployé sur le CDN et la modification y sera enfin présente.

 

Félicitations ! Vous avez appris à mettre en place une architecture de JAMstack utilisant Gatsby, Netlify CMS, Git et Microsoft Azure mais il est maintenant bien sûr temps de modifier votre solution afin que le site web généré réponde à vos attentes. Pour ce faire, vous souhaiterez sûrement :

 

→ Découvrir Gatsby et ses subtilités

→ Découvrir comment configurer Netlify CMS pour répondre à tous vos besoins

→ Découvrir les meilleures librairies de composants React pour réaliser votre site WEB de manière rapide et responsive

Kevin Ouahmad

Consultant Versusmind

L’article Développez votre site WEB à l’aide de la JAMstack est apparu en premier sur Versusmind.

L’article [Que sont-ils devenus ?] Johan Theron – Fondateur Quicommence.fr est apparu en premier sur Versusmind.

L’article Être consultant pour un grand acteur du retail – Témoignage de Julien Conseil est apparu en premier sur Versusmind.

Il y a quelques années, les spécialistes du marketing avaient prédit que l’expérience deviendrait plus différenciante que le prix ou la qualité d’un produit. Aujourd’hui, cette idée s’est très largement généralisée et on assiste au développement progressif de nouvelles expertises et technologies centrées sur les utilisateurs. 

 

Au premier rang de celles-ci, les systèmes de gestion de contenus (CMS) se sont progressivement enrichis et transformés en Plateforme d’Expérience Digitale (DXP). Ils associent ainsi les données clients, les données analytiques et des fonctionnalités d’automatisation du marketing afin de créer une expérience client totalement personnalisée sur l’ensemble des canaux. Sitecore, par ses multiples atouts, se place d’ailleurs comme la solution de référence en matière de gestion de l’expérience en ligne.

 

En parallèle de ces solutions, l’UX Design est devenu une expertise de plus en plus plébiscitée en France et dans le monde, démontrant projet après projet son intérêt et sa valeur ajoutée.

 

Dans cet article, nous vous proposons un retour sur le travail préalable d’expertise UX/UI et de compréhension des utilisateurs finaux, indispensable à la pertinence des développements Sitecore et à la création d’une expérience mémorable.

UX/UI Design : quel est son rôle ?

Le Design d’Expérience Utilisateur, désigné plus généralement par l’anglicisme “UX Design”, est une expertise qui pense la meilleure expérience pour l’utilisateur à travers l’interaction avec une solution en corrélation avec les besoins business.

 

Les UX Designers accompagnent les clients dans la définition et la conception de leur(s) solution(s) pour répondre à une problématique ou une idée. Les UX Designers aident les clients à se recentrer sur les besoins de leurs utilisateurs finaux et pas leurs propres besoins en faisant appel à l’empathie. On cherche ici à mettre en avant les idées qui auront le plus de sens pour les utilisateurs finaux, en faisant appel à des outils et méthodes UX (ateliers, questionnaires, études, etc).

 

Dans un projet de développement, l’UX s’intègre dès la phase de travail préliminaire durant laquelle les experts vont “construire les fondations” du projet. Cette étape permet un réel gain de temps et d’argent pour les clients et les équipes qui auront pensé, anticipé et testé les choses avant le développement. Enfin, elle permet également aux clients – et finalement ses utilisateurs finaux – d’adhérer à la solution puisqu’ils sont intégrés dès le processus de conception. 

 

L’UI Design, User Interface Design ou Design d’Interface Utilisateur, est un des champs d’application de l’UX et renvoie à la conception d’interfaces utilisateurs via des maquettes, par exemple.

 

Sitecore : une technologie conçue pour s’adapter à chaque utilisateur

 

Bien que ces tâches puissent être menées séparément, il est impensable de développer un projet sous la technologie Sitecore sans analyse UX préalable. En effet, les fonctionnalités de personnalisation de Sitecore requièrent une très bonne connaissance des différentes cibles. Cela rend donc cette technologie très intéressante aux yeux d’un UX Designer, car elle permet de personnaliser les contenus et les parcours en fonction du type d’utilisateur, ce qui n’est pas le cas avec les autres CMS.

 

En clair, on propose le bon parcours à la bonne personne pour adapter et améliorer son expérience. 

 

Côté pratique, comment ça fonctionne ? En amont du développement, les techniciens du projet mettent en place des règles définies en fonction des persona (établis par les UX Designers en respectant la nomenclature Sitecore) dans le back-office.  Par exemple, il peut s’agir la langue du navigateur, du type de supports utilisés ou la provenance géographique de l’utilisateur.

Dans un projet classique, l’étape de maquettage réalisée par les UI s’effectue selon une idée de parcours, d’écrans et d’interactions avec les éléments. Pour une implémentation de type Sitecore, on ajoute à cette réflexion le composant qui va avoir une vie en fonction de son contexte. Il est très important pour les techniciens de prendre en compte cet aspect fonctionnel.

” Sitecore offre un processus d’expérience complet puisqu’il s’adapte tout au long du parcours de l’utilisateur. C’est très intéressant pour nous, UX Designers. “

Laure Daguindau, responsable du pôle UX de Versusmind

Les 4 étapes clés de l’UX Design lors d’un projet Sitecore

1- Découverte et définition des parcours utilisateurs

En premier lieu, l’équipe UX organise des ateliers de découverte et de définition qui lui permet de récolter toutes les informations sur la problématique du client et ses utilisateurs finaux. En s’appuyant sur les hypothèses du client, les UX Designers construisent des protos personas et s’appuient sur les données statistiques ou la documentation existante (questionnaires, relevés analytics, etc). L’objectif de cette première étape est de comprendre le client et ses attentes.

2- Analyse fonctionnelle

Dans un second temps, l’équipe UX et les décideurs du projet se réunissent avec l’équipe d’Assistance à Maîtrise d’Ouvrage (AMOA) à l’occasion d’ateliers d’analyse fonctionnelle. Les différents acteurs créent ensemble la proposition de valeur du projet (créer de l’émotion positive pour les utilisateurs finaux). Le rôle de l’AMOA est de transformer les besoins fonctionnels du client en spécifications techniques, en élaborant un cahier des charges et un plan d’actions. Il est le facilitateur du projet, garant de sa fluidité et il coordonne et conseille les équipes.

3- La conception et les tests

La troisième étape est celle de la conception. Cette partie UI – User Interface – est indispensable dans un projet. Les designers entament la conception de maquettes en basse-fidélité (travail sur l’ergonomie) et haute-fidélité (avec application du design). Les maquettes peuvent être testées par des “bêta testeurs” via des prototypes interactifs afin de valider en amont l’expérience utilisateur. Cette validation préalable permet d’éviter les coûts de développement supplémentaire.

4- Le développement, la mise en ligne et l’amélioration continue

Enfin vient la phase de développement par les équipes techniques. Tout du long, l’équipe UX accompagne les développeurs en tant que garante de l’expérience utilisateur. La solution est ensuite livrée au client et mise en ligne. Le suivi et l’amélioration s’effectuent par l’étude des données analytics via Sitecore ou des outils comme Hotjar, par exemple.

Comment évaluer la réussite d’un projet Sitecore en terme d’expérience utilisateur ?

De manière générale, le travail d’analyse des résultats s’effectue par l’équipe UX qui, en amont, définit des KPI, des Metrics et des Heat Maps* au niveau de l’interface. Ce travail est ensuite implémenté par l‘équipe technique qui configure l’outil. Enfin, suite à la mise en production publique ou privée, ces outils et données sont livrés au client ou business analyst qui peut juger de la pertinence de son projet. On cherchera à vérifier les hypothèses et voir si les utilisateurs arrivent aux objectifs fixés.

*Carte de fréquentation : c’est une représentation graphique de données statistiques qui fait correspondre à l’intensité d’une grandeur variable une gamme de tons ou un nuancier de couleurs sur une matrice à deux dimensions.

UX Design et Sitecore : trouver le bon partenaire

Le pôle UX Design de Versusmind a vu le jour en 2018 et est intervenu sur 4 projets Sitecore depuis sa création. Aujourd’hui, l’équipe est composée de quatre experts qui possèdent chacun leur spécialité.

Conscient que la collaboration est la clé du succès d’un projet, Versusmind met un point d’honneur à faire travailler ses équipes en synergie et notamment en intégrant l’expertise UX dans les projets Sitecore. L’entreprise est d’ailleurs l’une des seules intégratrices à proposer une offre complète en synergie avec ses différentes expertises et équipes.

D’une part, l’équipe UX/UI de Versusmind prend en compte la valeur ajoutée de Sitecore : ses multiples fonctionnalités de personnalisation. D’autre part, au niveau technique, les chefs de projet et développeurs savent évaluer ce qui est faisable ou non. Par ailleurs, à chaque étape de la conception, un technicien challenge les équipes. L’objectif est de travailler de manière intégrée, sans silo d’implémentation et d’intégration détachés.

” En tant que responsable Sitecore chez Versusmind, je pense tout de suite à intégrer la partie UX, business analyse et construction technique dans un projet. Cela fonctionne et les gens arrivent à se parler. “

 

Jérôme Lalouette, Digital Practice Manager chez Versusmind

 

De plus, ce fonctionnement permet aux différents interlocuteurs (clients, architectes, UX Designers, techniciens) de se comprendre mutuellement, réconcilier les univers, savoir se parler et trouver des solutions communes. L’enjeu est de ne pas entamer le développement tant qu’une décision finale n’a pas été prononcée : le résultat doit être conforme aux maquettes, sans provoquer de surcoûts. Cette gouvernance garantie aux clients un budget stable et maîtrisé.

 

Versusmind a déjà testé ce fonctionnement à l’occasion d’un projet avec une grande compagnie de télécommunication. Le résultat est un travail engagé qui implique l’ensemble des collaborateurs du projet dans la réflexion et sa mise en oeuvre.

 

Vous souhaitez en savoir plus sur l’offre Sitecore de Versusmind ? Consultez notre site dédié et découvrez notre brochure : https://versusxperience.com/xperience

Versusmind est partenaire et intégrateur Sitecore. Notre connaissance de cette technologie alliée au pôle UX/UI ainsi que notre capacité d’approche marketing et technique permettent à notre équipe de consultants expérimentés et certifiés d’intervenir sur l’ensemble des phases d’un projet Sitecore. 

 

Le pôle Sitecore de Versusmind, tout comme l’équipe UX, est transversal à tous les pôles : l’AMOA (construction de l’architecture de la solution), les développeurs et intégrateurs et les équipes commerciales (avant-vente). Les équipes Sitecore de Versusmind sont également spécialisées dans les technologies Microsoft Azure, qui concernent la partie infrastructures et permettent notamment de faire émerger un site sur du Cloud.

 

@DePhiless

Philippe Didiergeorges

Développeur et architecte .Net et Javascript – MVP Visual Studio & Development Technologies

L’article UX/UI Design & Sitecore : ne passez pas à côté de ce facteur clé de réussite ! est apparu en premier sur Versusmind.