Dernièrement, on m’a posé la question de savoir si un bon PM doit savoir coder.
Notre conviction chez Thiga est qu’il n’existe pas de parcours classique pour devenir PM : on peut venir du dev comme du marketing ou du métier et donc ne pas savoir coder. Le plus important, c’est de maîtriser les basiques dans un ensemble de domaines (voir notre article sur les carrières produit), dont la Tech.
Et ça tombe bien, je te propose un article condensé, pour éclaircir les principaux termes techniques que tu entends tous les jours dans ton équipe sans toujours saisir ce qui se cache derrière.
La partie Front-end
- Derrière ce terme de “Front-end” (ou “Front” pour les intimes), on retrouve la partie visible de l’application, les interfaces pour les utilisateurs (aussi appelé IHM pour Interface Homme-Machine). On parle d’applications natives (pour une application iOS ou Android) ou de web app pour les applications accessibles via un navigateur sans besoin d’installation.
Vous avez sûrement entendu parler d’HTML, CSS et Javascript, non ? Ce sont ces langages (ou leurs dérivés) qui sont utilisés pour développer cette partie Front. Et ici, chacun son rôle: - Le HTML pour définir l’ossature du site. Il définit l’ordre des éléments et c’est aussi ici qu’on retrouve tous contenus statiques (textes et images notamment).
- Le CSS pour ajouter la couche graphique du site (couleurs, tailles et syles de polices, règles d’affichage notamment).
- Le Javascript pour rendre dynamique le site. On peut y définir l’action à exécuter par rapport à une action (clic sur un bouton par exemple) mais aussi les interactions avec d’autres applications (Google Analytics, entre autres)
Dernier point important concernant le Front : Le “Responsive design” ! Cette appellation décrit le comportement spécifique d’un élément en fonction de la taille d’écran et/ou du device. Seul le CSS (couche graphique) évolue pour avoir un site lisible et facile à naviguer sur toutes les tailles d’écrans et offrir une expérience optimisée, notamment sur mobile.
Quand un site est conçu principalement pour une utilisation mobile, on parle de design “Mobile first” (ce sont aux autres formats d’écrans de s’adapter).
La partie Back-end
Ici, pas d’interface visible. On retrouve plutôt la partie algorithmique et l’implémentation des différentes règles métier. Ce back-end est aussi celui qui permet d’accéder à la base de données.
Centraliser les règles métier dans le back-end offre l’avantage d’avoir les mêmes, quel que soit le canal d’affichage (app vs site web).
Historiquement, ce back-end était constitué d’un seul code centralisé que tout le monde pouvait modifier (appelé monolithe). Depuis plusieurs années, les bonnes pratiques poussent à une architecture éclatée en micro-services, c’est-à-dire que notre back-end est désormais constitué de plusieurs back-ends, chacun ayant son périmètre, et qui savent interagir facilement entre eux.
Ce changement d’architecture technique a un avantage organisationnel en permettant de gérer plus finement l’ownership du code : une équipe peut désormais avoir son micro-service qu’elle seule peut modifier.
A de rares exceptions près, les langages de programmation Front-end et Back-end sont différents. Un développeur pouvant travailler sur le Front-end et le Back-end est appelé un développeur full-stack.
Les API
Les API (Application Programming Interface) permettent de faire communiquer Front et Back. Elles servent aussi à faire communiquer 2 back entre eux, que ce soient 2 micro-services d’une même application, ou avec des services externes. Pour en savoir plus sur les API, je te conseille cette vidéo.
Pour faciliter la communication entre ces systèmes, les APIs ont des contrats d’interface qui spécifient :
- les données attendues en entrée,
- le traitement qui sera fait,
- les données en sortie,
- les codes retour et leur spécification
Les API REST standardisent la manière de spécifier les contrats d’interface via notamment une nomenclature facilitant la compréhension de l’action du service.
Les codes retour sont aussi standardisés avec de manière macro :
- codes 200 à 299 : Requête effectuée avec succès
- codes 300 à 399 : Redirections (pas forcément un problème)
- codes 400 à 499 : Erreurs côté client (navigateur). Vérifie si la page existe (404) ou si tu as les droits d’accès à la page (401, 403)
- codes 500 à 599 : Erreurs côté serveur. Va consulter les logs de ton serveur ou demande à ton dev favori ;)
Pour plus d’exhaustivité, c’est par ici : https://fr.wikipedia.org/wiki/Liste_des_codes_HTTP
L’hébergement et les échanges avec les serveurs
- Et pour finir, quelques notions d’infrastructure. Sais-tu comment ça fonctionne quand tu consultes une page web ? Voilà ce qui se passe derrière le rideau quand tu tapes “https://www.media.thiga.co/tag/product-management” par exemple dans ton navigateur :
1. Le navigateur envoie une requête pour récupérer le code HTML de la page “Product Management” qui se situe sur le serveur hébergeant media.thiga.co et stocké dans un dossier nommé “tag”
2. Le navigateur interprète le contenu de la page “Product Management” reçu pour afficher les informations nécessaires
3. Le navigateur voit dans le code HTML qu'il y a un fichier style.css à récupérer au même endroit et un fichier JavaScript script.js. Il appelle donc le serveur pour récupérer ces fichiers.
4. Le navigateur applique alors le style CSS et le javascript reçu et le site s’affiche correctement
“Vide ton cache”, le premier réflexe d'un développeur quand une anomalie est remontée. Ce cache est une manière d’optimiser les appels réseau du navigateur. Lors de la première consultation de la page "Product Management“, on a récupéré les fichiers CSS et JavaScript associés. Ces fichiers peuvent être stockés par le navigateur, dans ce fameux cache. Si tu reviens consulter la même page, le navigateur n’appellera pas le serveur pour récupérer ces fichiers mais il ira les chercher dans son cache. Hélas, le navigateur n'est pas au courant si le fichier sur le serveur a changé d'où ce besoin de vider le cache côté navigateur.
Côté Serveur, le stockage du code, des données ainsi que la gestion des performances sont généralement délégués à des hébergeurs Cloud, donc dans des serveurs mutualisés opérés par le fournisseur. Les 3 principaux sont Google Cloud Platform (GCP), Microsoft Azure et Amazon Web Services (AWS).
L’hébergement Cloud s’oppose à l'hébergement “On Premise” où la gestion de la plateforme et l’hébergement des données sont gérés par l’entreprise elle-même. La maîtrise des données est plus forte mais cela a un coût de maintenance non mutualisé et donc plus important.
Pour finir, peut-être qu’on t’a parlé de CI/CD (Continuous Integration/Continuous Delivery). Derrière ces notions, on retrouve l’automatisation des tâches facilitant :
l’intégration du code de chacun dans un endroit commun (appelé “repository”) tout en s’assurant qu’il n’y ait pas de régression (Continuous Integration)
le déploiement sur les différents environnements (Continuous Delivery).
L’un des outils phare de CI/CD est Jenkins. Ces pratiques apportent qualité et rapidité.
J’espère que cet article t’a permis d’éclairer ces différentes notions. La prochaine étape, c’est de mettre les mains un peu plus dans le cambouis, et pourquoi pas avec notre formation “Tech 4 PM”.
