Perplexity AI, une licorne qui promet de rendre Google “ringard” (ce sont les mots exacts de son PDG), c’est fait prendre en plein scrapping de données.
Et ce n’est pas la première fois.
Qu’est-ce que Perplexity AI ?
Si vous n’êtes pas un abonné de la planète tech, il y a des chances que vous ne connaissiez pas encore Perplexity AI.
C’est un mélange entre un moteur de recherche et un chatbot surboosté à l’IA générative. Perplexity AI se distingue de ChatGPT parce qu’elle fournit des résultats basés sur des données en temps réel (avec ses sources).
Et il bat Google en proposant des réponses condensées et dénuées d’hallucinations.
La startup a été cofondée en 2022 par un ancien d’Open AI, et en mars 2024 elle a réussi à élever sa capitalisation boursière à 1 milliard de dollars. Ce qui en fait une licorne.
Certains voient ce tout nouveau moteur de recherche comme le remplaçant de Google. Un combat qui rappelle vaguement Google contre Firefox et Internet Explorer…
Comment la supercherie a été découverte ?
Maintenant qu’on a fait entrer l’accusé, voyons ce qui lui est reproché.
Robb Knight, développeur chez Radweb et créateur du blog technologique rKnight, reproche à Perplexity AI d’ignorer les instructions des fichiers robots.txt.
Ce sont ces fichiers qui permettent aux webmasters d’interdire aux robots des moteurs de recherche — les crawlers ou spiders — d’accéder à certaines pages.
Or, Perplexity AI ne le respecte pas du tout, ce qui lui permet de voler des données sans être repéré.
Tout commence en mars 2024.
Robb Knight décide de bloquer Perplexity AI sur son blog.
Pour y parvenir, il ajoute l’agent utilisateur du moteur de Perplexity – Perplexity Bot -dans la liste noire de son fichier robots.txt.
Ensuite, il décide de vérifier si le moteur de recherche/chatbot IA a encore accès à ses contenus.
Il lui passe l’URL d’un de ses articles et lui demande de le résumer.
Et là…
Perplexity le lui résume avec tellement de détails que c’est impossible de croire que l’intelligence artificielle les a devinés.
« L’IA ne vaut que ce que valent ceux qui la supervisent. Je suis un adepte de l’IA et, entre de bonnes mains, la productivité, les progrès et la prospérité sont au rendez-vous. Mais entre les mains de personnes comme Aravind Srinivas, PDG de Perplexity AI, qui a la réputation d’être doué pour les techniques de doctorat et moins doué pour les aspects humains fondamentaux, l’amoralité pose un risque existentiel ».
Aravind Srinivas PDG de Perplexity AI
C’est que Forbes aussi, a remarqué le vol de contenu de Perplexity AI.
Et ils n’apprécient pas du tout.
Non seulement, tous les contenus (payants et exclusifs) de Forbes sont accessibles via Perplexity, mais la firme ne les cite même pas.
En plus de ne pas respecter ce concept, voler des contenus et se les approprier à des répercussions graves :
ça prive les créateurs de contenus de leurs sources de revenus (c’est ce qui s’est passé quand Forbes a retrouvé ses histoires exclusives sur Perplexity) ;
le trafic vers les sites web sources baissent.
Pour les éditeurs et les entreprises journalistes, c’est une attaque à leur business model.
C’est le nombre d’années qui s’est écoulé depuis la release de numpy 1.0.
Numpy est un peu le couteau de suisse des mathématiques sous Pythons. Grâce à cette bibliothèque, vous pouvez gérer simplement des matrices, des polynômes et toute une kyrielle de fonctions mathématiques.
Tous ceux qui font des maths l’utilisent. Des statisticiens. Des data scientists. Des professionnels du machine learning et j’en passe.
Des versions mineures se sont succédé entre temps.
Mais cette fois-ci, la communauté derrière le projet à juger les changements trop importants pour rester dans une version 1.xx.
Et ils ont eu raison au vu de ce que la nouvelle version de bibliothèque propose.
Quelques nouvelles fonctionnalités de NumPy 2.0
Sans transition, voici quelques-unes des annonces les plus marquantes de Numpy 2.0 :
un nouveau type de chaîne de longueur variable StringDType ;
un nouvel espace de noms numpy.strings avec des ufuncs plus performantes ;
une nouvelle API de traçage opt_func_info ;
la possibilité d’utiliser des objets Pickle dépassant 4GB ;
l’amélioration de l’API C et la migration du code C vers le langage de programmation C++ ;
une plus grande vitesse d’exécution grâce aux bibliothèques x86-simd-sort, Google Highway et Apple Accelerate.
Vous avez financé le développement d’une application, et vous souhaitez la faire évoluer, mais votre développeur refuse catégoriquement de vous donner le code source.
Vous pensez que c’est impossible ? Détrompez-vous.
De nombreuses sociétés sont en conflit avec les sociétés éditrices de leurs logiciels à cause de ça.
Sans compter celles qui ont modifié leurs propres programmes et se sont retrouvées assignées en justice pour contrefaçon.
Aujourd’hui, on va plus loin dans les enjeux de la propriété : on va vous montrer comment récupérer le code source de vos logiciels et les droits moraux qui vont avec.
Let’s go.
Pourquoi laisser le développeur avec le code est une mauvaise idée ?
Imaginez…
Votre site web ou application fonctionne à merveille.
Puis, vous vous dites qu’une nouvelle fonctionnalité rendrait vos équipes encore plus productives. Ou vous découvrez une faille de sécurité dans votre application mobile et cherchez à développer un patch.
Ou encore, vous souhaitez juste changer d’hébergeur ou de nom de domaine.
Bref, vous avez besoin d’accéder au code source, au repo GitHub et au serveur ftp.
Et là, les ennuis commencent : l’agence qui a développé votre plateforme numérique refuse de vous donner ces précieux accès.
Subitement, vous réalisez que vous ne pouvez plus vous passer du développeur — il a le contrôle sur votre solution informatique. Vous vivez dans une prison dorée et votre geôlier, c’est l’équipe de développement.
Voici ce qui vous attend :
des surfacturations pour la maintenance et les mises à jour ;
des arrêts de service imprévus ou des mises hors ligne du programme en fonction du développeur ;
de grosses pertes financières dues aux ralentissements de vos opérations ;
et je ne parle même pas des surcoûts pour développer le moindre nouveau module.
Vous avez le monopole d’exploitation et les licences, mais c’est le prestataire qui détient les droits de propriété littéraire et artistique.
Selon l’INPI (Institut National de la Propriété Intellectuelle), seul lui peut modifier son œuvre (autrement dit : vous êtes à 100 % dépendant de lui). Et si vous modifiez le logiciel, alors vous vous exposez à des contentieux.
Raison pour laquelle vous devez en parler avec lui et le mettre par écrit avant de signer le moindre contrat. Sans ça, gare aux litiges.
Chez Poyesis, on vous évite tous ces maux de tête en vous donnant accès au code source dès le début du projet.
4 solutions lorsque votre développeur refuse de vous donner accès au code source
Avant d’aller voir un cabinet d’avocat et de sortir l’arme juridique, voici quelques stratégies que vous pouvez essayer.
1 – Vérifiez votre contrat
Première étape, allez regarder le contrat ou l’acte de vente que vous avez signé avec l’équipe de développement.
Recherchez attentivement les clauses qui parlent de la propriété intellectuelle et de la livraison du code source. Si vous ne trouvez rien, jetez un œil à ses conditions générales de vente.
Dès le moment où le contrat stipule que vous êtes en droit de recevoir le code source, vous avez une base légale pour le lui réclamer.
2 – Cherchez un arrangement à l’amiable
Certains développeurs craignent de donner le code-source pour des questions de sécurité et de propriété intellectuelle.
Par exemple, vous faites appel à une agence web pour développer un CRM. Or, l’agence sait que d’autres entreprises peuvent être intéressées par un CRM identique.
Elle prévoit donc de réutiliser une partie du code source de l’application qu’elle a écrit.
Sauf que, si elle n’est plus détentrice des droits d’auteur, elle sera obligée de tout reprendre à zéro. Y compris l’architecture de l’information, l’organisation des bases de données et autres.
Si c’est votre cas, proposez-lui un compromis plus une clause de non-divulgation et ce sera réglé.
3 – Faites appel à un médiateur professionnel
Ultime étape avant les tribunaux : passer par un expert de la médiation.
Étant donné qu’il est neutre, son avis ne sera pas biaisé et son jugement sera plus facilement accepté par les deux parties.
Et si ça ne marche pas…
4 – Si tout échoue… montrez les crocs et portez l’affaire en justice
Voilà.
Si vraiment aucune des solutions présentées plus haut ne vous satisfait, allez voir un juriste spécialisé en conseil en propriété intellectuelle.
En effet, vous risquez d’être agréablement surpris selon la juridiction.
Et que si vous modifiez le programme sans que son créateur ne vous en ait donné le droit, vous risquez des actions en contrefaçon ?
Eh bien, la cour peut aller à l’encontre de cette législation en fonction de plusieurs paramètres.
Par exemple, en 2020, la cour d’appel de Boulogne a rendu le jugement n° 96/2020 dans lequel elle reconnaît que le titulaire des droits — et donc du code source — c’est le commanditaire du progiciel.
Autrement dit, vous.
3 ressources à lire absolument pour comprendre la jurisprudence des logiciels
Dans cet article, mon objectif était de vous montrer comment faire pour avoir accès au code source de votre logiciel.
Mais lorsque l’on parle de droits d’auteur, de propriétés intellectuelles et d’actifs immatériels, il vaut mieux laisser des juristes experts en matière de propriété intellectuelle s’exprimer.
Alors, je vous ai listé mes trois meilleures ressources pour comprendre les 50 nuances des subtilités juridiques des logiciels :
Pour éviter les tracas juridiques, soyez clair dans votre contrat : à la fin du projet, le code-source est à vous. Ajoutez une clause de cession des droits, ou mieux, un contrat de cession des droits.
Mentionnez clairement le transfert des droits de propriété pour jouir d’une protection au cas où ça tourne mal. Et si votre prestataire vous répond :« On verra ça plus tard », fuyez.
Chez Poyesis, on vous livre tout : accès ftp, répertoire de fichiers, dépôts, github… et bien sûr, le code-source. Après tout, on ne construit pas votre maison pour garder les clés, n’est-ce pas ?
Les statistiques du web mobile commencent à exploser.
Les entreprises de la tech flairent le filon des applications web responsives design accessibles via les navigateurs web.
Parmi elles, Facebook.
Sa première web app pour iOS est créée la même année. Sauf que les experts de l’expérience utilisateur du réseau social remarquent vite un gros problème : l’interface-utilisateur n’est pas fluide.
Les ingénieurs de la firme se creusent les méninges… et décident de créer une application mobile native pour iOS.
Et là encore, nouveau problème, leurs APIs REST renvoient trop d’informations et ne sont pas adaptées aux spécifications du développement mobile.
Les APIs REST consomment beaucoup trop de bande passante. Ralentissent la version mobile du réseau social. Et surtout, surchargent les serveurs en back-office pour rien.
De là, vient l’idée à Lee Byron et à deux de ses collègues de créer un nouveau langage de requêtes : GraphQL.
Publié pour la première fois en 2012, il devient open-source en 2015, et depuis, il ne cesse de séduire les développeurs web et mobiles.
Et aujourd’hui, on va parler de GraphQL, quels avantages vous pouvez en tirer et comment il fonctionne.
Let’s go.
Qu’est-ce que GraphQL ?
Pour comprendre GraphQL, vous devez savoir ce qu’est une API (si si, c’est important). Une API, ou “Application Programming interface”, est un ensemble de protocoles qui permettent à deux composants logiciels de communiquer.
Elles sont énormément utilisées dans les architectures client-serveur pour permettre à l’utilisateur de récupérer des données depuis une base de données.
C’est au concepteur-développeur de l’application de choisir et de concevoir l’interface de programmation qui sera utilisée.
GraphQL, ou Graph Query Language, est un langage de requêtes et un environnement d’exécution côté serveur pour API.
Sa particularité ? C’est la requête du client qui définit la structure des données qu’il veut.
Particularité qui a déjà séduit plusieurs entreprises, dont :
PayPal ;
Coursera ;
Dailymotion ;
GitHub ;
Meta.
Vous en trouverez plus en vous rendant sur le site de la fondation GraphQL (voici une partie de la liste).
Et cette nuance est importante. Car les autres APIs les plus utilisées sont les APIs REST (Representational State Transfer).
Et elles vous renvoient des informations prédéfinies par le développeur qui a conçu l’architecture serveur. Même si elles ne correspondent pas aux besoins de l’utilisateur.
Parfois, elles envoient trop de données, et côté client, on ne sélectionne que celles qui nous intéressent. On parle d’over-fetching.
Parfois, à l’inverse, elles n’envoient pas toutes les informations, ce qui oblige à faire plusieurs appels sur la base de données. On parle d’under-fetching.
Ces deux problèmes peuvent être évités grâce à une API GraphQL.
Comment fonctionne une API GraphQL ?
Au sein d’une API GraphQL, toutes les requêtes sont des requêtes POST avec, en attribut, une structure de données.
Et c’est la structure de données passée en paramètre qui contient les noms des attributs que l’on souhaite recevoir en retour.
À l’intérieur du code de l’API, vous trouverez deux catégories de données :
les données « Types » ;
les données « Champs ».
Et parmi les objets, vous trouverez 3 types d’objets différents :
les objets « Requêtes », qui contiennent toutes les requêtes acceptées par l’API et qui vérifient que les formats reçus sont autorisées ;
les objets « mutation » qui définissent toutes les actions possibles et qui permettent de faire des modifications sur les modèles définis ;
les objets « abonnement », qui définissent les modèles de la base de données.
Bon, ok, tout ça, c’est un peu théorique.
Alors voici un exemple de code-source.
On va définir, en GraphQL, une structure de données représentant un concessionnaire automobile (juste son nom et son emplacement). Ensuite, on va récupérer son emplacement.
Voici ce que ça donne.
type Concessionnaire { nom: String emplacement: String voitures: String }
Définition du graphe de données.
Vous voyez à quel point c’est simple ? Let’s go pour un appel en javascript.
const { ApolloClient, InMemoryCache, gql } = require('@apollo/client'); // Remplacez l'URL par l'endpoint de votre serveur GraphQL
Clairement, on fait comprendre au serveur qu’on ne veut que l’emplacement et rien d’autre.
Ainsi, pas besoin de filtrer le résultat qu’il retourne.
Si on fait la même chose avec une API REST, voici ce que ça donne :
const axios = require('axios');
// Remplacez l'URL par l'endpoint de votre API REST const restEndpoint = 'https://votre-api-rest.com/concessionnaires';
// Effectuez une requête GET pour récupérer les données axios.get(restEndpoint) .then(response => { const concessionnaires = response.data; const emplacements = concessionnaires.map(concessionnaire => concessionnaire.emplacement); console.log('Emplacements des concessionnaires (REST) :', emplacements); }) .catch(error => { console.error('Erreur lors de la récupération des données (REST) :', error); });
Ici, on récupère toutes les informations des concessionnaires. Et après ça, on extrait le champ qui nous intéresse.
Imaginez un peu si on avait plus d’informations sur les concessionnaires :
Des images de plusieurs centaines de voitures au format .png ;
Des vidéos de présentations ;
Des dizaines d’informations textuelles supplémentaires, etc.
Devinez quoi ? On aurait dû tout transférer depuis les serveurs avec une API REST pour, au final, ne garder qu’une seule colonne.
Bon, c’est un peu exagéré, généralement, on définit une API spécifique qui ne renvoie que des données précises pour chaque cas. Mais vous voyez l’idée.
Pourquoi GraphQL est (parfois) un meilleur choix qu’une API REST ?
Quel API choisir pour concevoir vos logiciels ? À quels protocoles allez-vous faire confiance pour le transfert de vos données ?
Le cabinet Postman a posé la question à plusieurs développeurs dans le monde. Et voici les résultats qu’ils ont obtenus :
Dans les faits, 89 % des devs utilisent des APIs Rest dans leur pile technique contre à peine 29 % pour les APIs GraphQL (ils pouvaient choisir plusieurs réponses).
2ᵉ réponse : les avantages et les inconvénients de GraphQL.
Et justement, voyons-les tout de suite.
3+1 Avantages de GraphQL
GraphQL a 4 avantages majeurs comparé à REST.
1 – Vous évitez l’under-fetching
L’under-fetching se produit lorsqu’une requête ne retourne pas toutes les données dont le programmeur a besoin.
En conséquence, il doit encore faire un appel serveur et initier un autre transfert de données pour avoir toutes les informations qu’il veut.
Vous sentez la dégradation des performances de votre app venir ?
Du moins, ça se passe comme ça dans une API Rest.
Dans une API GraphQL, vous n’avez pas ce problème. Vous demandez des données, et le serveur vous les retourne, un point c’est tout.
2 – Vous évitez l’over-fetching
L’over-fetching est l’autre face de l’under-fetching.
Il se produit lorsque vous avez besoin d’une information, mais que l’API vous retourne tout un tas d’autres données dont vous n’avez pas besoin.
Sur les APIs REST, c’est fréquent.
On fait un appel à la base de données via une API dont les champs retours sont déjà spécifiés. Ensuite, après avoir consommé la bande passante du serveur et du client, on jette tous les champs qui ne nous intéressent pas.
Du gaspillage pur.
Et ça empire si vous avez besoin de données sur le même serveur, mais accessibles via des API différentes.
Heureusement, avec GraphQL, ça ne se produit pas.
Le développeur précise clairement les champs qu’il attend et le back-end lui fournit uniquement ceux-là.
Vous vous souvenez de l’extrait de code qu’on vous a fourni plus haut avec le concessionnaire ? C’est exactement ce qui s’y passe.
Avec l’API Rest, malgré le fait que l’on ne souhaite avoir que l’emplacement, on télécharge d’abord toutes les données renvoyées par le serveur.
L’over-fetching est particulièrement énervant pour les applications mobiles et web car elle les ralentit fortement.
3 – Gérer les versions n’a jamais été aussi simple
Vos applications évoluent. Les versions se succèdent et parfois ne se ressemblent pas.
Très souvent, vous ajouterez ou retirerez des fonctionnalités de l’app.
Problème : vos équipes de dev vont devoir modifier les champs retournés par l’API.
Si vous utilisez REST, apprêtez-vous à de longues journées à chercher exactement quelles fonctions dépendent de quelles APIs.
Essayez de retirer un champ dans une API alors qu’il est critique pour une fonction utilisant cette API… et une pluie de bugs informatiques et de crash vont vous tomber dessus.
À l’inverse, rajoutez trop de champs dans vos APIs pour faire tourner vos nouvelles fonctions, et vos systèmes informatiques vont ralentir. Sans compter les risques de vulnérabilité accrus aux cyberattaques.
Bref, la gestion des versions d’un logiciel va vous obliger à aller toucher à vos APIs et aux requêtes serveurs qui les utilisent.
Sauf si vous utilisez GraphQL.
Alors non, les APIs GraphQL ne sont pas immuables. Mais elles ont une meilleure rétrocompatibilité, sont plus simples à faire évoluer et à adapter à vos nouveaux besoins.
4 – GraphQL vous facilitent l’accès aux données éparpillées dans plusieurs bases de données relationnelles
Voici ce à quoi ressemble l’architecture des bases de données typiques des grands groupes :
Vous voyez où je veux en venir ? Les informations peuvent être contenues dans différents serveurs situés à des emplacements géographiques différents.
Et c’est logique : si votre entreprise ouvre une branche à Paris, vous voudrez très probablement stocker les informations de vos clients de Paris à proximité de Paris. Question de simplifier l’accès aux données de vos collaborateurs qui gèrent ces clients.
Par contre, vous n’avez pas besoin de dupliquer les informations de votre département Ressources Humaines sur place. Vous les garderez donc près de votre siège.
Et si, comme tous les GAFAM, vous décidez d’installer votre siège européen à Dublin, devinez quoi ? Vous allez assurément y stocker les informations sur vos ventes, vos finances, etc.
Pourquoi je vous parle de ça ?
Pour vous faire comprendre que vos données peuvent facilement être éparpillées dans des data centers aux 4 coins du monde.
Et il n’est pas rare que vous ayez besoin, dans une seule requête, d’informations situées dans plusieurs data centers différents.
Vos équipes de développement vont devoir faire appel à plusieurs APIs. Ensuite faire des JOIN/Merge en SQL entre les clés primaires et secondaires de leurs retours.
C’est fastidieux. Ça consomme énormément de ressources (électricité + bande passante). Enfin, ce flux de SELECT, JOIN et de MERGE diminuent la durée de vie de votre infrastructure informatique.
Pour au final ne récupérer que peu d’informations.
Avec une couche GraphQL, les performances de telles requêtes vont considérablement s’améliorer, car il s’appuie sur des technos web.
Grâce à l’ajout d’une couche de GraphQL, les pages qui chargeaient 10 MB de données n’avaient plus besoin que de 200 KB. Et les performances globales du système ont fait un boost de x8.
Les 4 inconvénients majeurs de GraphQL
Après tout ce qu’on a dit plus haut, on peut être tenté de se dire que GraphQL est la solution technique à tous vos problèmes.
Attendez.
Parce que les API GraphQL ont aussi leurs défauts.
1 – Pas de mise en cache côté serveur (ou trop complexe)
Avec une API Rest, vous savez exactement quelles informations le client va vous demander.
Et si le même client demande les mêmes informations plusieurs fois, vous pouvez les mettre en cache côté serveur pour gagner en vitesse.
C’est impossible ou très peu envisageable avec une API GraphQL.
La raison : la structure des données retours n’est pas définie côté serveur.
Une tactique utilisée par les développeurs GraphQL est de mettre les informations dans le cache du client. C’est moins efficace, mais ça marche.
2 – La courbe d’apprentissage du langage de requête peut être abrupte
REST est une norme d’échanges d’informations créée en 2000.
Ça fait 24 ans qu’elle est enseignée par défaut aux geeks et autres passionnés d’informatique par défaut.
Tous ceux qui s’intéressent aux codes informatiques et à la gestion des données doivent maîtriser par cœur la formule CRUD des API REST. (CRUD = CREATE READ UPDATE DELETE).
En conséquence, la transition du modèle CRUD vers les schémas, résolveurs, souscriptions et graphes de GraphQL peut s’avérer difficile.
3 – Il y a peu de développeurs spécialisés sur cette technologie (comparée aux API REST)
Si vous ne voulez pas, ou n’avez pas le temps de faire une montée en compétence, l’autre solution est d’embaucher un expert maîtrisant cette technologie.
Sauf que, vous vous en doutez, ils sont moins nombreux que ceux maîtrisant les interfaces de programmation d’applications REST.
En écrivant ces lignes, je suis allé faire un tour sur Fiverr, l’une des marketplace de freelance les plus populaires au monde.
J’ai fait une recherche sur le terme « Développeur API GraphQL » et ensuite, j’ai filtré les prestataires parlant français et/ou anglais.
Bilan : 1.444 prestataires ( et à peine 75 qui parlent au moins le français)
À l’inverse, les développeurs d’API REST parlant français et/ou anglais sont 15.180 ! (et 656 quand je ne prend que ceux qui parlent français).
Je vous laisse faire les calculs vous-mêmes pour voir la différence de taille dans le vivier de talents disponible sur la technologie GraphQL.
4 – Sécuriser les serveurs est plus compliqué
Sécuriser un serveur utilisant une API GraphQL présente des défis en termes de cybersécurité plus importants qu’avec une API REST.
La raison ? les réponses des points terminaux (les clients) ne sont pas statiques comme dans une API REST.
Bien sûr, il y a des moyens pour les sécuriser, sinon Facebook et tous les autres géants de la tech ne l’utiliseraient pas 😉
Et hop, transition parfaite pour le prochain point.
Comment sécuriser son API GraphQL ? (4 méthodes)
Logo de GraphQ
On est d’accord, GraphQL a ses avantages, si ça fait de votre système informatique une passoire pour hacker, hors de question de l’utiliser.
Heureusement, il existe une myriade de techniques pour transformer vos API GraphQL en coffres-forts anti-hackers.
1 – Restreindre les autorisations
Oui, GraphQL permet à l’utilisateur de demander les données qui l’intéressent.
Mais encore faut-il qu’il ait l’autorisation de lire tous les champs de données qu’il demande.
Raison pour laquelle, l’un des moyens les plus sûrs pour diminuer le risque d’attaque informatique est de limiter les autorisations.
Couplé à une politique d’authentification robuste et le chiffrement des données et vous êtes presque invulnérable.
Enfin, une autre technique consiste à surveiller les activités de l’API pour identifier et neutraliser les menaces. Ainsi, même si les identifiants d’un utilisateur sont compromis, vous pourrez rapidement repérer la source de l’attaque et la bloquer.
2 – La validation des requêtes de l’API
L’API peut être une source d’attaque.
Comment ? Il suffit que l’attaquant demande des informations sensibles ou injecte du code malveillant via un appel-serveur.
Évitez ça.
Pour cela, rien de plus simple : pensez à toujours vérifier les inputs/outputs de l’API et à les nettoyer au besoin.
Ça vous évitera notamment des attaques par injection.
3 – Gérez la complexité des requêtes avec soin
Vous vous souvenez de ce que l’on disait que GraphQL permet de limiter l’under-fetching en récupérant directement toutes les données ?
Ça aussi, ça peut être une source de vulnérabilités informatiques.
Si un individu malveillant parvient à faire une requête profonde, il peut récupérer un lot d’informations sensibles. Ou pire, il peut surcharger les serveurs qui hébergent vos données via une attaque par déni de service DDoS.
Pour parer à ça, une seule solution : limitez la profondeur et l’étendue des requêtes.
4 – Soyez vigilant sur les demandes d’introspection
L’introspection est une fonctionnalité de GraphQL qui permet au développeur de connaître le schéma de votre base de données.
Elle révèle absolument tous les champs… ce qui peut vite devenir problématique si un individu malveillant utilise cette fonction.
Raison pour laquelle il est nécessaire de toujours restreindre et gérer soigneusement les données exposées via les points de terminaison.
Comment faire pour implémenter une API GraphQL ou une API REST sur votre projet ?
Ok.
À ce stade, vous savez ce qu’est GraphQL (et REST, vu que j’en ai beaucoup parlé). Et vous voulez savoir si ça peut booster les performances de votre application web/mobile ou de votre logiciel.
Alors comment faire ?
J’aimerais bien vous donner une réponse type faite A puis B puis C, seulement, votre projet est unique. Et les solutions techniques dont vous avez besoin le sont aussi.
Et plus elle est complexe, plus vous avez de chance de vous retrouver dans l’une des situations suivantes :
vos équipes de développement prennent de plus en plus de temps pour intégrer les nouveaux morceaux de code ;
vos testeurs détectent les bugs tardivement ;
le respect des délais de livraison passe d’un “impératif” à un “on va essayer d’être dans les temps”.
Bref, les problèmes techniques vont vous sauter à la gorge et risquent de faire couler votre projet.
Heureusement, l’ingénierie logicielle et l’approche DevOps ont développée une solution pour chasser ce nuage noir : l’automatisation via un pipeline CI/CD avec Jenkins et Gitlab.
Qu’est-ce qu’un pipeline CI/CD et comment il dope la productivité de vos développeurs ?
Un pipeline CI/CD est une série d’étapes à réaliser durant le développement d’un logiciel.
Son objectif : simplifier le développement logiciel en améliorant la distribution des nouvelles versions d’un logiciel via des tests automatisés.
Il est chargé de surveiller, d’automatiser les tests manuels extrêmement chronophages durant tout le cycle de vie du logiciel. Y compris lors de la phase d’intégration et celle du déploiement.
A chaque étape, le développeur rédige un ou plusieurs scripts qui seront exécutés à des moments précis du processus de livraison.
Dis comme ça, ça peut ressembler à une description d’un théorème obscur sorti tout droit de l’almanach d’un savant fou. Mais c’est en fait un gage de la qualité du code final et de votre capacité à respecter le cahier des charges dans les temps impartis.
Pour comprendre à quel point un pipeline CI/CD va transformer vos processus de création d’applications, il y a 2 concepts essentiels : l’intégration continue (CI) et le déploiement continu (CD).
L’intégration continue CI
Comment faire pour être certain que l’ajout de nouvelles fonctionnalités dans le code-source ne va pas entraîner de problèmes de compatibilité ?
Comment être certain que tous les membres de vos codeurs ont exactement la même version du code que celle de la branche maîtresse ?
Ou que le retrait ou la modification d’un bout de corde ne va pas créer une cascade d’erreurs liées aux dépendances ?
Malheureusement, c’est impossible à garantir.
Surtout si votre code source est composé de milliers de lignes de codes, d’une kyrielles de dépôts et de packages entremêlés (bref, un bon gros plat de spaghetti informatique 🍝).
Par contre, ce que vous pouvez faire, c’est vérifier automatiquement s’il y a une erreur à chaque modification d’un morceau de code.
C’est le principe de l’intégration continue (ou continuous integration, dans la langue de Shakespeare).
Pour citer wikipedia : “L’intégration continue (de l’anglais : Continuous integration, CI), est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l’application développée”.
L’intégration continue permet aux programmeurs de ne plus avoir à tester manuellement si leurs modifications créent des bugs.
L’outil d’intégration analyse constamment les dossiers dans lesquels se trouvent les codes. Et s’il détecte un commit ou un git push dans votre SCM, il lance la compilation de la nouvelle version du code. Ensuite, il lance l’exécution des tests (tests fonctionnels, tests de régression, tests d’intégration, tests d’acceptation, etc.).
A la fin, le programmeur reçoit un rapport de tests lui indiquant s’il y a des erreurs et comment les corriger.
Le déploiement continu (CD)
Réduire le Time-to-Market de vos app pour fournir une valeur client plus rapide vous intéresse ?
Si oui, vous allez adorer la livraison continue (Continuous Delivery) et le déploiement continu (Continuous Deployment).
Concrètement, à chaque commit, la livraison continue va effectuer des tests automatisés et intégrer le code. Ensuite, elle attend une validation humaine pour déployer la dernière version du logiciel dans les différents environnements de tests, d’intégration et de mise en production.
Le déploiement continu va faire exactement pareil. A une différence près : son processus de déploiement automatisé ne nécessite aucune validation humaine.
Et pour pouvoir mettre en place un pipeline mêlant le CI et le CD, vous allez avoir besoin d’outils d’intégration.
Ce qui nous conduit à nos deux champions du jour : GitLab CI/CD et Jenkins.
Qu’est-ce que GitLab CI/CD et Jenkins ?
D’emblée, sachez que vous pouvez utiliser uniquement l’un ou l’autre, ou les deux, en fonction de votre cahier des charges et de votre équipe.
Maintenant, voyons-les en détail.
GitLab
GitLab est un logiciel de gestion de versions (VCS) complet fortement orienté sur la collaboration et le travail en équipe.
Et parmi ses fonctions, GitLab CI/CD.
GitLab CI/CD est un outil de gestion de l’intégration continue et du déploiement continu des projets hébergés sur GitLab.
Parmi ses fonctionnalités, voici quelques-unes qui sont très appréciées par les aficionados du code informatique :
la gestion du code source ;
l’intégration d’outils de monitoring et d’analyse ;
le suivi complet des problèmes ;
l’usage de la syntaxe YAML ;
son intégration native avec Git.
Toutefois, contrairement à ce que leurs noms peuvent laisser penser, GitLab et GitHub appartiennent à des entreprises différentes.
GitHub, racheté par Microsoft en 2018, est une autre solution open-source répondant aux mêmes besoins.
Néanmoins, les deux sont basés sur le même logiciel de versions décentralisé et open-source : git.
D’où la ressemblance dans les noms.
Jenkins
Créé en 2004 sous le nom de projet Hudson, Jenkins était d’abord un logiciel interne dédié à l’intégration continue pour l’équipe de développement de Sun Microsystems.
Hudson gagne en popularité grâce à son modèle communautaire, flexible et rapide. Sauf qu’en 2009, Oracle rachète Sun et veut imposer sa vision du processus de développement idéal d’un logiciel.
Plus lent. Plus contrôlé. Bref, moins agile et radicalement différent de la conception des créateurs originaux.
Raison pour laquelle, en 2011, les développeurs originels de Hudson créent un fork du projet sur GitHub. C’est ce fork qui est devenu Jenkins.
Alors qu’est-ce que jenkins et à quoi ça sert ?
Jenkins est un serveur d’intégration continu open-source écrit dans le langage de programmation Java.
Il est 100 % gratuit et mise sur la flexibilité et la rapidité des livraisons.
Autre point fort de Jenkins : son immense bibliothèque qui contient plus de 1900 intégrations à d’autres outils pour passionnés du code informatique.
2 – Configurez les variables d’environnement pour Java
Les variables d’environnement sont utilisées pour dire en gros à votre OS :”voici où il faut chercher les fichiers qui contiennent les commandes de Java”.
Ainsi, lorsque vous écrirez des lignes de commande sur votre serveur virtuel Jenkins, l’ordinateur saura où aller chercher.
Rassurez-vous, c’est extrêmement facile :
Allez dans system -> Paramètre système avancé > Avancé ;
cliquez sur les variables d’environnement ;
sélectionnez Java_Home et entre le chemin de navigation suivant : C:\Program Files\Java\jdk-[Numéro de votre version Java] ;
Dans l’onglet variables système, ajoutez le chemin du fichier Java bin C:\Program Files\Java\jdk-[Numéro de votre version Java]\bin ;
C’est tout.
3 – Téléchargez et configurez Jenkins
Maintenant que votre desktop est configuré pour Java, passons à la prochaine étape : installer Jenkins.
Ca aussi, c’est très simple à faire en quelques clics.
choisissez “exécuter le service en local ou en tant que “domaine utilisateur”;
Attendez patiemment que l’installation se termine.
Voilà, Jenkins est installé sur votre machine.
Maintenant, il faut le “débloquer”.
Pour cela :
ouvrez votre navigateur internet et allez sur http://localhost:8080
Sur l’écran qui s’ouvre, entrez le mot de passe créé par Jenkins dans les fichiers logs (ils sont ici : C:\Program Files\Jenkins\secrets\initialAdminPassword)
Entrez le mot de passe.
Créez votre tout premier utilisateur – sans oublier de lui donner le rôle d’administrateur – et le tour est joué.
Etape 2 – Créez un nouveau projet Freestyle ou Pipeline sur Jenkins
A cette étape, vous avez déjà un serveur Jenkins qui fonctionne.
Place à la création du pipeline.
Voici la marche à suivre :
Allez sur Gitlab et copiez l’URL de votre référentiel (le répertoire de travail dans lequel se trouve votre projet) ;
Connectez-vous sur Jenkins ;
Allez dans les préférences ;
Créez un token, ou jeton d’accès, personnel ;
Stockez votre token dans un fichier texte ;
Créez un nouvel item et choisissez “Freestyle project”;
Dans l’onglet “Source Code Project Management”, choisissez Git et collez l’URL de votre projet sur Gitlab ;
Rajoutez des étapes dans votre pipeline si nécessaire (celles par défaut font parfaitement l’affaire pour de petits projets) ;
lancez le build.
Et voilà. A chaque fois que l’équipe de développement modifiera le code stocké sur le compte Git, l’instance Jenkins effectuera toutes les étapes que définies dans votre pipeline.
De plus, vous pouvez aussi modifier votre code directement dans l’interface web de l’IDE de Jenkins.
Vous n’aurez plus qu’à aller dans l’espace “workspace” sur Jenkins pour lancer le build.
Étape 3 : configurez vos pipelines Jenkins
Pour modifier le pipeline créé par défaut, vous allez devoir ouvrir le jenkins file du projet. C’est le fichier de configuration de votre pipeline.
Il se trouve à la racine du projet.
Un jenkinsfile est un simple fichier texte dans lequel vous allez écrire vos instructions dans un langage spécifique à un domaine – ou DSL.
Celui de Jenkins ressemble beaucoup à du code Groovy.
Vous avez le choix entre deux modes d’écriture :
Le mode déclaratif, plus simple, adapté aux débutants et aux projets de petite envergure. Pour l’utiliser, téléchargez le plugin Pipeline Declarative ;
Le mode scénarisé, plus complexe et plus puissant, qui s’écrit dans le langage Jenkins Job DSL fourni avec le plugin pipeline.
Après avoir téléchargé le plugin correspondant à vos attentes, installez un environnement de programmation (IDE). Visual Studio Code fera parfaitement l’affaire.
Voici un exemple de fichier Jenkins en mode déclaratif.
Bonus : Comment créer un pipeline CI/CD uniquement avec GitLab
Vous vous souvenez, plus haut nous vous avons dit que vous pouvez utiliser soit l’un, soit l’autre pour créer votre pipeline CI/CD ?
Eh bien, c’est extrêmement simple : vous n’avez qu’à créer un fichier avec l’extension .gitlab-ci.yml à la racine du référentiel GitLab.
Ensuite, vous définissez les différentes étapes de votre pipeline CI/CD et le tour est joué.
Voici quelques sections les plus courantes dans ces fichiers:
Stages : définit les différentes étapes du pipeline, chacune ayant un nom significatif.
+install : dans cette étape, il y a un job appelé install_Dependencies qui s’occupe de l’installation des dépendances du projet en utilisant la commande npm install. C’est une étape courante pour s’assurer que les dépendances sont à jour.
+Cache :l’étape Node-Modules-Cache utilise une fonction de mise en cache pour stocker le répertoire node_modules/ entre les exécutions de jobs. Il permet d’économiser du temps en évitant de réinstaller les mêmes dépendances à chaque exécution.
+build : c’est ici qu’à lieu la construction de l’application.
+security :inclut des tâches liées à la sécurité du code telles que les analyses statiques de sécurité SAST et les analyses dynamiques de sécurité (DAST).
variables : définit les variables d’environnement qui peuvent être utilisées dans les jobs du pipelineDe
Voilà, maintenant vous savez tout ce qu’il y a à savoir sur les pipelines CI/CD avec Jenkins et GitLab.
On aimerait tous que lorsque nos prospects voient un de nos supports de communication, ils s’exclament « ah, c’est l’entreprise X ! » avec un sourire aux lèvres.
C’est ce que font Apple, Coca Cola, McDonald’s et bien d’autres.
Quel est le secret de ces marques pour rendre leur univers de marque reconnaissable et inoubliable ? Et surtout, comment est-ce que vous aussi pouvez le mettre en pratique.
La réponse est simple : créez votre charte graphique.
On vous montre ça tout de suite.
Qu’est-ce qu’une charte graphique ?
Loin d’être une lubie coûteuse des studios de création graphique, la charte graphique est un document indispensable à toute marque.
C’est le cahier des charges qui forge l’identité visuelle forte qui vous permet de vous différencier visuellement de la concurrence.
Tous les éléments graphiques utilisés par votre entreprise doivent s’aligner avec ce précieux cahier des charges pour designer.
Voici les éléments que l’on retrouve dans une charte graphique :
Le logo ;
La palette de couleurs à utiliser ;
Les icônes :
Le ton et la voix de votre marque ;
Les polices d’écriture/typographies à utiliser ;
Un guide pour choisir les illustrations et autres images à utiliser.
Créer une charte graphique présente 3 gros avantages :
Construire une marque forte et reconnaissable partout et par tous ;
Fédérer une communauté autour de la marque ;
Se différencier de la concurrence.
Voyons les plus en détails tout de suite.
Construire une marque forte et reconnaissable partout
Est-ce que vous connaissez quelqu’un qui s’est acheté une Mercedes ?
Oui ?
Faites un petit test : demandez-lui pourquoi il l’a fait.
Après tout, il y a des dizaines d’autres marques plus fiables, avec de meilleures finitions et de meilleures performances.
Pourtant, votre connaissance a jeté son dévolu sur la firme allemande.
La raison : c’est parce que Mercedes ce n’est pas que des véhicules, c’est avant tout une communauté, un style de vie (et un signe d’appartenance à un groupe).
Si Mercedes a pu le faire, c’est en partie grâce à sa charte graphique.
Sa charte graphique, qui se ressent sur tous ses produits et supports de com, en fait une marque reconnaissable.
Et c’est exactement la même chose que votre charte graphique fera pour vous : vous offrir une image de marque forte et séduisante aux yeux de votre clientèle.
Fédérer une communauté autour de la marque
Toute votre charte graphique tournera autour de vos clients, de vos valeurs et des émotions que vous voulez éveiller chez vos fans.
En gros, vous jouerez beaucoup sur les informations inconsciemment perçues par vos prospects.
Par exemple, vous voulez renvoyer un sentiment de confiance et de professionnalisme ? Optez pour une nuance de bleu en couleur primaire et un logo carré ou arrondi.
Logo de PayPal
Logo du crédit lyonnais
Logo de la Deutsche Bank
Logo citibank
À l’inverse, vous tenez un fast-food et voulez susciter de l’enthousiasme et de l’appétit ? Mettez du rouge, de l’orange et du jaune partout.
Logos enseignes de fastfood
Intérieur d’un fastfood
Toutes ses informations vont influencer les attentes des prospects envers votre service.
Ils s’attendront à vivre une certaine expérience. Et si vous leur fournissez l’expérience utilisateur qu’ils attendent (voire plus), bingo : vous avez des fans.
Différenciez-vous de vos concurrents
En un clic sur son smartphone, votre potentiel client a le choix entre des milliers de prestataires.
Dont vous.
Comment faire pour qu’ils vous choisissent vous, et pas un de vos concurrents ?
Créez une identité visuelle et une image de marque fortes et qui vous différencient du reste de votre marché.
Voici un exemple de charte graphique réussi : Slack
Brand Guidelines Slack
On ne présente plus Slack.
L’application de communication collaborative et de gestion de projet ultra-prisée par les entreprises de toutes tailles.
Mais une autre raison qui fait que Slack sert de référence chez les designers, c’est sa charte graphique.
En 50 pages et 3 sections, ce document détaille toute l’identité visuelle de la marque aux créatifs du monde entier.
Prêtez attention aux sections, elles peuvent vous inspirer pour créer votre propre brandbook :
Section 1 : Définition de la marque
Section 2 : Éléments du design
Section 3 : Gouvernance
Sommaire du brand Guidelines Slack
Allez, sans plus tarder, voyons comment créer votre propre charte graphique en 10 étapes.
Comment créer une charte graphique en 10 étapes top chrono
Avant de vous ruer sur Figma ou sur la suite Adobe, sortez votre bloc-note. Voici les 10 étapes à suivre pour donner vie à votre propre charte graphique.
1 – Définir son marché et sa niche
Avant de penser logo, images, couleurs et autres, commencez par analyser votre marché.
Quels services/produits vendez-vous ?
Quels segments de clientèle allez-vous viser ?
Quelle niche ciblez-vous ?
Sera-t-elle suffisante pour vous permettre de faire un chiffre d’affaires et des marges suffisantes ?
Quelles sont les valeurs qui comptent le plus aux yeux de vos futurs clients ?
Quelles sont les attentes dans votre secteur d’activité ?
Et quelles sont les pratiques de communication les plus utilisées dans ce secteur ?
Toutes ces questions vont vous permettre d’ajuster votre communication digitale et print pour mieux faire résonner votre marque avec vos clients.
En plus de vous différencier des autres entreprises déjà présentes s’il y en a.
2 – Définir vos buyer personas
Maintenant que vous avez déterminé la niche à cibler, il est temps de définir vos buyer personas.
Concrètement, ce sont les personnes qui vont acheter vos produits/services.
Voici les informations typiques d’un buyer persona :
les données démographiques (genre, ville, niveau d’études, distribution d’âge, profession, CSP, revenus, etc.) ;
les données comportementales (réseaux sociaux favoris, canaux de communication préférés, centres d’intérêts…)
ses besoins et attentes (qu’est-ce qui frustre vos prospects ? Quelles sont leurs motivations ? Leurs alternatives ? Leurs moments de vérité ?…)
leurs valeurs ( quelles sont les valeurs qu’ils recherchent chez une marque ?).
Remarquez bien : « Leurs valeurs » est en gras.
Car faire ressortir des valeurs dans votre identité visuelle et dans toute votre communication est l’une des missions principales de votre charte graphique.
3 – Analyser vos concurrents
Ici, il ne s’agit pas de rentrer dans une analyse technique des processus de vos concurrents.
Non.
Seulement leur communication. Voici les éléments auxquels vous devez prêter attention :
leurs positionnements marketing ;
les tons et les voix employés dans leurs éléments de communication (Google Ads, publicités, Facebook, vidéo promotionnelle, contenus web…) ;
leurs forces et faiblesses (faites une analyse SWOT de vos compétiteurs).
Pourquoi c’est important ?
Pour deux raisons :
d’un, vous saurez ce à quoi vos prospects sont habitués, ce qu’ils aiment et ce qu’ils détestent ;
ensuite, vous trouverez probablement un axe de différenciation encore inexploité ou sous-exploité.
Une fois que vous avez ça, il est temps de passer à la dernière étape de l’analyse : définir le cœur de votre brand.
4- Définir le cœur de votre marque
Maintenant, c’est l’heure de définir le cœur de votre marque.
Voici les 3 questions auxquelles vous allez devoir répondre :
qui sont vos clients ? (vos buyers personas) ;
quelles seront les valeurs phares de votre marque ? (au trop 3) ;
quelles émotions voulez-vous créer chez vos utilisateurs ?
C’est bon ? Maintenant, sortez vos crayons et passons enfin à une étape plus artistique.
5- La création du logo
De tous les éléments graphiques de votre identité visuelle, le logo est le plus important.
Et de loin.
Un bon logo coche obligatoirement les 4 cases suivantes :
Il va à l’essentiel tout en étant simple, reconnaissable et facile à imprimer ;
Il est intemporel et traverse les décennies sans devenir « has-been » ;
Fonctionne parfaitement sur les différents supports de communications physiques et numériques ;
Enfin, il transmet les valeurs et l’identité de votre marque d’un regard.
Oui, dis comme ça, ça fait beaucoup.
Mais il suffit que vous ratiez une seule de ces cases pour que votre logo vous crée un bad-buzz.
En voici un parfait exemple (essayez de deviner ce que cette structure vend).
Logo de mama’s baking
Vous avez trouvé ?
Il s’agit de recettes de cuisine. Les internautes avec des esprits plus pervers y ont vu autre chose😏…
On peut faire pire. Parfois, de bonnes intentions donnent naissance à des logos justes horribles.
Logo de Arlington Pediatric Center
Bon, heureusement depuis, ils ont refait un nouveau logo plus classique.
Nouvelle page d’Arlington Pediatric Center
N’empêche, lorsque vous tapez le nom du cabinet sur votre moteur de recherche… jugez les résultats vous-même.
Recherche google sur Arlington Pediatric Center
Allez, et un dernier pour la route.
Logo proposé pour l’Institut des Sciences Orientales de l’Université de Santa Catarina
6 – Définir les couleurs
Les couleurs transmettent des émotions et des symboles à notre inconscient.
Alors pour être certain de créer la bonne émotion (celle qui guide vers l’achat), choisissez les couleurs adaptées.
Précisez spécifiquement les nuances qui vous plaisent grâce à leurs codes RVB, HEX, CMJN et Pantone. Pourquoi spécifier leurs codes ? Car ça vous assurera d’avoir exactement les mêmes nuances sur papier que lors de vos campagnes numériques.
Palette de couleurs autorisées pour les logos de PayPal
Pour vous faire une idée de l’importance du choix des couleurs dans vos compositions graphiques, voici les significations de quelques couleurs populaires.
Le bleu
Synonyme de confiance, de sécurité, de fraîcheur, de professionnalisme et de royauté, le bleu est utilisé par :
les entreprises de nettoyage ;
les banques et les institutions financières ;
certaines organisations mondiales comme l’ONU, le FMI, la Banque Asiatique de Développement,etc. ;
le secteur du tourisme et du transport ;
les entreprises de perte de poids.
Surpris par le dernier ? Vous ne devriez pas. Le bleu est un coupe-faim notoire, raison pour laquelle les fast-foods et les marques alimentaires l’utilisent très peu.
Le rouge
Le rouge symbolise l’appétit, l’amour, la passion et l’excitation dans la plupart des pays.
Toutes les industries peuvent s’en servir, car à bonnes doses, le rouge nous pousse à l’action.
Par contre, si vous l’utilisez, faites attention au contexte dans lequel vous l’utilisez.
Parce que oui, le rouge peut aussi renvoyer à des concepts auxquels vous ne voulez peut-être pas être associé·e :
Le communisme ;
Les révolutions contre la tyrannie ;
Les idées de gauche ;
La mort dans certains pays d’Afrique (en référence au sang versé) ;
La chance en Asie.
Dernière couleur : le jaune.
Le jaune
Le jaune a ceci de particulier que c’est la couleur que l’œil humain traite la plus rapidement (source).
Ainsi, le jaune renvoie à la joie, à l’optimisme, à l’appétit et à la créativité.
Malheureusement, on ne peut pas vous faire un topo complet sur la psychologie des couleurs. Alors si vous voulez en savoir plus sur toutes les couleurs, faites un tour sur cet article d’Adobe.
7 – Choisir les polices de caractères
Avec ou sans empattement (sans serif en anglais) ?
Police plutôt féminine ? Masculine ? Enfantine ? Professionnelle ? Sérieuse ? New age ? Vintage ?
Vous l’avez compris, la typographie que vous choisissez va fortement impacter l’émotion ressentie par vos utilisateurs.
Alors pas question de la négliger.
Imaginez un seul instant si le logo de société générale utilisait la typologie arrondie et joyeuse de McDonald’s… vous leur feriez encore confiance ?
Voici les critères pour choisir vos polices de caractères :
toujours prendre une police lisible ;
toutes vos polices doivent s’harmoniser entre elles ;
assurez-vous que la police que vous choisissez comporte tous les caractères de l’alphabet de vos clients (certaines polices ne comportent pas de « é » ou de « ç » par exemple) ;
vérifiez que le rendu final de la police correspond à ce que vous allez en faire (allez-vous utiliser cette typo sur le web ou en print ?) ;
enfin, jetez toujours un œil sur les droits de la police : certaines ont des licences payantes ; d’autres sont gratuites jusqu’à un certain nombre d’impressions, etc.
Pour trouver des polices originales, faites un tour sur Google Font. Chaque jour, des milliers de créateurs ajoutent de nouvelles typographies, alors foncez.
Enfin, dernier conseil : jamais plus de 3 polices ( 1 pour les titres, 1 pour le corps du texte et 1 autre facultative pour mettre en valeur les citations).
Sinon, vous obtiendrez ça :
Image avec plusieurs typos différentes
Illisible, n’est-ce pas ?
Alors n’infligez pas ça à vos lecteurs.
8 – Définir une hiérarchie visuelle
La hiérarchie visuelle désigne la mise en pages des éléments sur tous vos différents supports de communication.
C’est grâce à ça que vous pouvez mettre en valeur des éléments de manière visuelle sans indiquer au lecteur « regarde ici, c’est important ! ».
Et c’est aussi quelque chose que vous pouvez rater si vous ne faites pas attention. Un exemple valant 1000 mots…
Affiche avec une mauvaise mise en page
Qu’est-ce qu’ils recherchent ? Un « apprentice » ou un « Rent Ice Ships » ou un App rent ice » ?
Réponse : ils cherchent un apprenti pour se charger de l’impression et du design graphique (et en ont visiblement besoin).
9 – un guideline pour choisir les photographies d’illustration
Photo d’homme sans pieds
Bon, soyons honnête : vous voyez cette photo sur une maquette de création de votre site e-commerce, vous allez vite faire une remarque à votre graphiste.
(Il lui manque des pieds, ce qui est gênant, à part si vous visez le métavers de Facebook).
Par contre, certaines photos d’illustration peuvent être réussies sans pour autant correspondre à l’image de marque que vous voulez renvoyer. De plus, à chaque fois qu’un internaute voit une image sur vos plateformes, il doit reconnaître un fil conducteur.
Voici quelques images de PayPal.
3 affiches publicitaires de PayPal
Vous voyez le fil conducteur ? Il y a toujours un élément en bleu qui se détache du reste, sans pour autant être un logo.
À force d’être exposé à ces images, l’esprit de sa clientèle fait un raccourci bleu=PayPal.
Et pour être certain que ce schéma soit présent dans toutes les photos d’illustration, PayPal le mentionne clairement dans son brand book :
Règles de choix des photos d’illustration chez PayPal
En français, ça donne ceci :
« Un accent de bleu sur un fond désaturé ajoute une qualité unique à nos photographies et communique que le PayPal fait partie de la vie de tous les jours. Lorsque vous décidez de ce que vous allez « bleuir » dans vos images, le bleu du ciel et le bleu de l’eau ne comptent pas comme « touche de bleu ». Vous pouvez choisir quelque chose de petit, comme une boucle d’oreille ou une chaussure, ou quelque chose de grand, comme un chapeau ou un vélo. C’est à vous de choisir. »
Pratiquement toutes les entreprises ont une section dédiée aux recommandations des photos d’illustration. Même la SNCF en a.
Guideline pour le choix des photos dans le brand book de la SNCF
Ici, il s’agit de montrer comment utiliser la forme de la « motrice » et la mettre en avant sur les photos (en plus d’indiquer clairement le type de photographies acceptées).
Maintenant, passons à la dernière partie.
10 – Définir des règles d’utilisation pour lutter contre les débordements créatifs
Les règles d’utilisation sont vos garde-fous face à des designers beaucoup trop créatifs.
En effet, ce n’est pas rare qu’un graphiste essayant un nouveau concept, se retrouve totalement hors de l’image de marque.
C’est pour cette raison que vous avez tout intérêt à rajouter des contraintes et des règles inviolables.
En voici quelques-unes :
Éviter de mettre des textes sur des arrière-plans de certaines couleurs ;
Ne pas étirer le logo ni le recadrer ;
Ne pas modifier les couleurs du logo ;
Ne pas associer certaines couleurs ensemble.
Dans son brandbook, Slack dédie toute une section à ce qu’il ne faut surtout pas faire à son précieux logo.
Déformations interdites du logo de Slack
Ça y est !
Vous avez toutes les clés en main pour créer une charte graphique ou superviser celle fournie par votre chef de projet informatique.
…
Mais on a un dernier cadeau pour vous.
3 bons conseils pour créer une mauvaise charte graphique
Bon, nous nous doutons que vous voulez créer une identité visuelle reconnaissable et qui vous démarque de la concurrence.
Et c’est ce que nous vous avons montré jusqu’ici.
Mais on peut aller encore plus loin en vous montrant 3 choses à ne surtout pas faire lorsque vous créez votre charte.
Let’s go.
1 – Créer une charte qui ressemble trop à celle d’une autre entreprise
Adagio Access est une entreprise spécialisée dans l’hôtellerie et la location de résidence en Europe pour voyageurs aux budgets serrés.
De son côté, Direct energie (aujourd’hui Total Energies Électricité et Gaz France) est, ou était, un fournisseur d’énergie alternatif.
Et là, vous êtes sûrement en train de vous demander quel est le rapport entre les deux. Leurs logos !
Jugez par vous-même.
Logo de Direct Energie
Logo de Adagio Access
Même cercle rond et jaune, polices presque identiques… pourtant ce sont deux entreprises de deux secteurs d’activité différents.
Et c’est cette spécificité qui a fait que les deux ne sont pas lancés dans une guerre juridique sur fonds de propriété intellectuelle. Et elles ne sont pas les seuls dans ce cas.
Logo de Pepsi à gauche vs celui de Korean air à droite
(logo de pepsi à gauche, celui de Korean Air à droite)
Par contre, lorsque les deux entreprises sont dans le même secteur d’activité, bonjour la confusion chez les clients (et les aller-retours aux tribunaux). C’est ce qui est arrivé entre Starbuck et Starpreya, deux coffee-shop en Corée du Sud.
Logo de starbuck à gauche vs celui de StarPreya à droite
Alors conseil d’ami : assurez-vous d’avoir une identité visuelle très différente de celles de vos concurrents.
Enfin, ce conseil n’est pas valable si vous assumez pleinement de plagier une autre marque. Ainsi, depuis le début des sanctions contre la Russie et le retrait des entreprises occidentales, de nouvelles marques sont apparues.
Magasin Stars Coffee en Russie
Plagiat de McDonald’s en Russie
Logo de Swed House, un IKEA russe
Le moins que l’on puisse dire, c’est que le plagiat est très clairement assumé.
2 – Ignorer les opinions de vos clients
GAP est une chaîne de vêtements fondée en 1969 et qui a la particularité d’être populaire chez les personnes de tout âge.
En 2010, modernité et reprise post-crise des subprimes obligeaient, GAP a décidé de changer son logo emblématique pour un plus… minimaliste (c’était la tendance graphique à l’époque).
Ce qui nous a donné un cas d’école d’un des pires fails de rebranding, le GapGate. Ça :
2 logos de Gap
(l’ancien logo utilisé depuis 1990 est à gauche, le nouveau est à droite).
Pourquoi est-ce que les fans l’ont mal reçu ? Pour plusieurs raisons :
il manque cruellement d’originalité ;
le changement de logo signale une nouvelle orientation aux clients, alors que là, rien n’a changé pour eux ;
à cause des ventes décevantes de l’année 2010 (10 % de moins qu’avant), les fans ont pris ce rebranding comme un mouvement de panique.
Ron Johnson’s, le talentueux esprit derrière les génialissimes Apple Store, est porté à la tête de JC Penney.
L’espoir et la hype autour de la marque sont immenses.
Johnson’s va appliquer toutes les recettes qui ont fait son succès chez Apple… en opérant un rebranding de la marque :
Exit le nom « JC Penney’s », désormais, ce sera juste « JCP » pour faire moderne et chic (pour une enseigne spécialisée dans le low-cost et les prix justes🤔);
Le logo aussi passe à la trappe, il devient carré ;
Les magasins aussi sont totalement reconfigurés (il y avait même un bar comme ceux des Apple Store) ;
le système des prix a été au mieux remplacé, au pire complexifié, et les remises de prix ont été supprimées.
Sur le papier, cette nouvelle identité de marque devait doper les ventes. Sauf que c’est le contraire qui s’est produit.
En 17 mois, l’entreprise a perdu 552 millions de dollars.
Surprenant venant d’un ex d’Apple. Il a réussi à créer de la confusion chez les consommateurs d’une marque vieille de plus d’un siècle.
Et quelle meilleure illustration que ses 3 changements de logos en 17 mois ?
Evolution du logo de JCP
Bien sûr, à chaque fois que la marque « évoluait », toute son identité de marque faisait de même.
En 2012, changement de CEO et retour au bon vieux logo de JCPenney (celui de 2010 sur l’image).
Moral de l’histoire : ne modifiez pas votre charte graphique et vos éléments de communication trop souvent, au risque de semer la confusion chez vos fans.
Est-ce que vous vous êtes déjà demandé pourquoi IKEA vend de la glace à la sortie de ces magasins ?
…
C’est pour créer une expérience utilisateur inoubliable et introuvable chez un autre vendeur de meubles.
Sauf que bon, vous n’êtes pas IKEA, et le titre de l’article, c’est “comment faire l’audit UX de son site web”. Pas de son magasin de meubles.
Bonne nouvelle, ça s’applique aussi à vos plateformes numériques (dont vos applications web).
Et si vous souhaitez booster l’expérience vécue par vos clients, vous devez commencer par auditer l’UX que vous proposez.
Justement, voici comment le faire en 9 étapes.
Qu’est-ce que l’expérience utilisateur ?
Importance des couleurs des boutons en UX design
L’User eXperience désigne toutes les émotions, perceptions, réactions physiques et psychologiques de vos utilisateurs. Et surtout, l’expérience utilisateur concerne toutes les étapes du parcours client, y compris avant et après qu’il n’ait utilisé votre produit/service.
Selon Peter Morville, l’un des pionniers de l’architecture informationnelle, l’UX est composée de 7 facteurs :
L’utilisabilité : est-ce que votre site web ou application mobile est facile à utiliser ?
L’utilité : vos services répondent à un besoin de votre cible ?
La désirabilité : est-ce que vos plateformes numériques suscitent une émotion positive ? Sont-elles esthétiquement réussies ?
La trouvabilité : vos contenus sont aisés à trouver ?
L’accessibilité : tous les internautes peuvent consommer vos contenus ?
La crédibilité : est-ce que votre marque fait figure d’autorité (coucou Google EEAT😏) ?
La valeur : est-ce que vous apportez une réelle valeur à vos prospects ?
Aussi simples soient-ils, ces 7 éléments peuvent faire toute la différence entre une entreprise prospère et un dépôt de bilan.
L’UX design est un investissement, pas une dépense (ou 7 statistiques qui vont convaincre votre boss d’investir dans l’UX)
Si vous avez lu notre billet sur les 32 lois de l’UX design, aucun doute que vous êtes convaincu de l’importance de l’UX.
Oui, mais certains de vos collaborateurs ne le sont pas. Right ?
Il n’est pas rare que l’UX UI design soit relégué à une tâche à faire lorsque l’on aura le temps. Pire encore, si l’entreprise cherche désespérément de nouveaux clients : il y a de fortes chances que tout ce qui ne fasse pas rentrer le cash immédiatement soit mis de côté.
Et améliorer l’UX design de ses plateformes numériques tombe souvent dans la deuxième case.
Sauf que c’est une erreur.
Et voici 7 raisons pour lesquelles vous et vos collaborateurs devriez prendre le temps de faire un audit UX design.
1 – Son ROI explose celui de tous vos canaux marketing (et de loin)
Autant commencer par le nerf de la guerre, le retour sur investissement.
En effet, lorsque certaines entreprises veulent augmenter leur CA, elles investissent massivement dans la publicité.
Et quel est le ROI des canaux de webmarketing ?
L’e-mail : 1 € investi = 42 € en retour ;
Le SEO : 317 % pour les e-commerces ;
Les publicités Google Ads : 1 € investi = 2 € en retour ;
1 € investi dans un UX designer = 99 € en plus dans votre trésorerie.
Le site ESPN.com a fait le pari de l’UX design en retravaillant son site web en fonction de ses users personas. Verdict : ses revenus ont grimpé de 35 % !
2 – Vous éviterez la cause d’échec de 70 % des business en ligne
Oui oui, vous avez bien lu.
70 % des entreprises online finissent par mettre la clé sous le paillasson à cause… d’une expérience utilisateur désastreuse (source).
Faites partie des 30 % de gagnant en pensant UX.
3 – Vos taux de conversion vont exploser (et vos ventes avec)
L’UX design vise à augmenter la satisfaction utilisateur.
Et un utilisateur satisfait est un client qui achète.
C’est la conclusion d’une étude de Forrester research, les entreprises qui soignent leur expérience utilisateur voient leurs CRO bondir de +400 % (source).
Enfin, regardez ce qu’il se passe lorsque vous n’offrez pas une bonne expérience utilisateur à vos mobinautes.
Plus exactement, si votre site/application a un temps de chargement élevé :
Nombre d’utilisateurs qui quittent une appli en fonction de son temps de chargement. Source : Statista
Maintenant que vous êtes convaincu·e de l’importance de l’UX expérience, reste plus qu’à répondre à la question : qu’est-ce que l’audit UX ?
Un audit UX est une analyse de l’expérience utilisateur qui repose sur 2 briques essentielles :
L’analyse de l’ergonomie de vos interfaces ;
L’analyse comportementale de vos utilisateurs.
À la fin de l’audit UX UI, vous connaîtrez :
les points de friction qui empêchent vos utilisateurs de vivre un parcours fluide (en plus d’éloigner leurs CB de vos formulaires d’achats) ;
leurs besoins réels (besoins ≠ d’envies) ;
comment optimiser vos processus d’onboarding ;
comment améliorer vos KPIs business et la performance de votre plateforme ;
enfin, vous découvrirez comment améliorer vos taux de conversion.
Sans transition, voici 9 étapes pour mener l’audit UX de vos plateformes numériques.
9 étapes pour mener son audit UX
En suivant ces quelques instructions, vous devriez réussir sans grand mal à faire un audit rapide de vos interfaces.
Let’s go.
1 – Définissez l’objectif de l’audit et les KPI à monitorer
Est-ce que vous allez auditer une caractéristique de votre app ? Une interface ? Un parcours utilisateur ? Ou alors tout votre système ?
Faire un audit UX demande énormément de temps (en plus d’avoir un coût non négligeable).
Par conséquent, si votre site web contient beaucoup d’interfaces et de fonctionnalités, vous allez devoir choisir.
Armez-vous d’un stylo et d’une feuille et répondez aux trois questions suivantes :
Quelles fonctionnalités vais-je auditer ?
Quelle(s) métrique(s) business, je souhaite améliorer : CTR ? Nombre de leads ? Nombre de nouveaux clients ? Valeur moyenne d’un panier ? La lifetime value ? Taux de rétention d’un segment utilisateur précis ?
Concernant les KPI, voici une liste non exhaustive que vous pouvez utiliser :
le taux de rebond ;
la durée des sessions utilisateurs ;
le taux d’abandon de panier ;
le trafic par page ;
le nombre de clics de rage (c-a-d les clics répétés sur un élément graphique en une courte période de temps – c’est un symptôme typique d’un bug, d’une erreur JavaScript ou d’un point de friction qui énerve votre internaute) ;
les micros conversions.
Après ça, vous n’avez plus qu’à mettre les membres de votre équipe dans le bain. Typiquement, voici les profils dont vous aurez besoin :
1 UX designer, qui va déceler les pains points et les points de friction pour proposer des solutions fluides ;
1 ou plusieurs développeurs pour mettre en œuvre les recommandations de l’audit ;
Les membres de votre support client, car c’est chez eux que vos clients parlent de ce qu’ils n’apprécient pas dans vos services ;
1 product manager qui va vous apporter des insights pertinents grâce à sa connaissance de vos clients, des objectifs du produit et de sa vision créatrice.
Même si ça peut sembler tentant de le faire tout seul, souvenez-vous d’une chose : vous n’êtes pas du tout objectif.
Car après tout, c’est votre produit, vous avez assisté à sa conception et y êtes émotionnellement lié. Avoir les visions d’autres personnes pour vous recadrer est donc impératif.
Une fois que c’est prêt, vous êtes prêt pour la prochaine étape.
2 – (Re)faites une recherche utilisateur et créer vos personas utilisateurs
Citation Jakob Nielsen
Là, vous vous dites peut-être que vous connaissez déjà parfaitement vos personas marketing. Et donc faire une recherche sur eux est inutile.
Erreur.
Parce qu’il ne s’agit pas de vos buyer persona. Mais de vos personas utilisateurs.
Là où un persona marketing se focalise sur l’acheteur, le persona en UX design est orienté sur les comportements et les biais cognitifs de l’utilisateur (pas de l’acheteur).
son objectif : qu’est-ce que votre persona désire obtenir en utilisant votre produit ?
sa motivation : Pourquoi est-ce qu’il veut atteindre cet objectif en particulier ?
son approche : comment est-ce qu’il compte atteindre leur objectif ?
Sa frustration : qu’est-ce qui l’empêche d’atteindre son objectif ?
Sans ces informations, vos designers auront du mal à concevoir des cartes d’empathie et des experiences map. Autrement dit, ils n’arriveront pas à créer des parcours qui vont déclencher des émotions chez vos utilisateurs.
Pour créer vos personas UX, voici les étapes à suivre :
faites des hypothèses sur vos utilisateurs : qui sont-ils ? Comment se comportent-ils face à vos interfaces ?
sélectionnez un panel d’utilisateurs et faites leur passer des entretiens un à un ;
effectuez des tests utilisateurs et recueillez les feedbacks ;
affinez vos hypothèses en vous basant sur vos données utilisateur : grâce à des outils marketing comme Google Analytics, Kissmetrics, Crazy Egg, etc. ;
enfin, n’hésitez pas à espionner vos concurrents pour analyser leur expérience utilisateur.
Point important pour la suite : connectez au moins un outil d’UX à votre logiciel. C’est capital pour la suite.
Une fois que c’est prêt, passons à la prochaine étape.
3 – Identifiez les chemins suivis par vos utilisateurs
Expérience utilisateur vs les parcours conçus
Si vous avez déjà conçu une app, vous vous reconnaîtrez sûrement dans cette image.
Supposez que vous conceviez un processus de checkout pour un site e-commerce. Vous faites les hypothèses suivantes :
l’utilisateur parcourt vos fiches produits ;
sélectionne quelques items puis les mets dans son panier ;
ensuite, il rentre ses informations de paiements ;
puis son mode de livraison préféré ;
après quoi, il prévisualise sa commande ;
et il paie.
Voilà.
Ça vous semble logique et vous vous dites que vos clients suivront (logiquement) ce processus.
Sauf que, plot twist, certains vont créer des itinéraires non-prévus.
Par exemple :
après avoir mis des articles dans son panier, l’utilisateur décide finalement de les retirer ;
au moment de rentrer ses informations de paiement, beaucoup d’utilisateurs quittent votre site web sans raison ;
ou encore il s’arrête pendant qu’il remplit ses coordonnées.
Bref, rien, absolument rien, ne vous garantit que les utilisateurs de vos plateformes vont suivre les chemins que vous avez créés.
D’où l’importance de confronter vos hypothèses avec des données réelles.
Et c’est là qu’entre en jeu Google Analytics.
Grâce à lui, vous obtiendrez des insights inestimables pour approfondir votre compréhension de vos utilisateurs :
le taux de rebond par page spécifique ;
la heatmap (carte montrant comment les internautes naviguent sur vos interfaces) ;
les périphériques via lesquels les internautes accèdent à vos contenus ;
les chemins utilisateurs (regardez dans l’onglet « Navigation summary ») ;
la durée de chaque session ;
le suivi des évènements (ex : télécharger un PDF, regarder une vidéo, cliquer sur un lien, et bien d’autres micro-conversions).
Et cette liste est loin d’être exhaustive.
Alors un conseil : foncez rapidement sur vos rapports Google Analytics.
4 – Evaluez votre réputation en ligne
À ce niveau, vous avez une meilleure connaissance de vos utilisateurs.
Et si vous sortiez un peu la tête de votre site web ?
Car oui, l’expérience utilisateur de vos clients débute bien avant qu’ils ne commencent à utiliser vos produits.
Tous les points de contacts situés en amont – réseaux sociaux, publicités, Google Ads, contenu marketing, etc. – doivent aussi être vérifiés.
Pourquoi ? Parce que vos consommateurs n’interagissent pas qu’avec les features de vos produits, mais avec l’histoire que votre marque raconte.
Citation Seth Godin
Si l’histoire racontée par votre marque est incohérente ou ne correspond pas aux croyances de votre utilisateur… votre UX et vos ventes vont en prendre un coup.
Non pas qu’elle soit mauvaise, non.
Seulement, vos prospects vont être frappés de dissonance cognitive.
Concrètement, votre site web ne fonctionnera pas comme ils pensent qu’il doit fonctionner.
Cette situation finit par créer une tension dans l’esprit du client qui va choisir de s’évader de vos plateformes.
Pour en revenir à nos moutons à notre audit UX, voici les points à vérifier :
l’image de marque renvoyée par vos réseaux sociaux est identique sur tous vos supports de communication (site web inclut) ;
les informations disponibles ailleurs sur le web correspondent à celles présentes sur vos plateformes ;
votre communication est cohérente avec vos avis clients.
Maintenant, revenons sur votre site internet.
5 – Vérifiez vos critères Core Web Vital
Lancés en 2021 par Google, les Core Web Vitals, ou Signaux Web Essentiels dans la langue de Molière, sont les indicateurs de la qualité de l’UX proposée par une plateforme selon Google.
Ce critère mesure la vitesse de chargement de vos pages. Pour obtenir une excellente note, l’élément le plus volumineux de votre page doit se charger en moins de 2.5 secondes.
Le LCP est majoritairement impacté par trois types d’éléments :
À leurs yeux, un contenu qui ne s’affiche pas correctement est une vraie incitation à passer chez vos concurrents.
L’usabilité sur smartphone est différente de celles sur PC. On n’interagit pas de la même manière sur desktop qu’avec un smartphone. Et ça se ressent dans vos parcours UX.
Ensuite, voici quelques éléments sur lesquels vous devez être particulièrement attentif :
la cohérence ;
l’accessibilité de l’information ;
l’esthétique de votre UI design.
Voyons-les en profondeur tout de suite.
1 – La cohérence
J’ai une mauvaise nouvelle à vous annoncer : vous n’êtes pas le seul sur votre marché.
Ah, vous le saviez déjà ?
Par contre, avez-vous anticipé que cela signifie que vos prospects s’attendent à ce que votre logiciel fonctionne d’une certaine manière.
Oui, je parle des standards.
Interface d’Adobe Photoshop
Interface de The GIMP
Remarquez à quel point les interfaces d’Adobe Photoshop et celles de son concurrent The GIMP se ressemblent.
Ainsi, un designer sait à peu près quel bouton donne accès à quelle fonctionnalité, peu importe l’outil.
En plus de respecter les standards graphiques et fonctionnels de votre industrie, vous devez aussi veiller à la cohérence entre vos pages.
Cohérence graphique (toutes vos pages doivent suivre la même charte graphique et avoir les mêmes schémas de couleurs) et cohérence fonctionnelle (les mêmes éléments de l’UI doivent avoir les mêmes fonctions sur toutes vos interfaces).
Garantir la cohérence au sein de votre site web a deux avantages :
faciliter la prise en main de votre logiciel par les nouveaux utilisateurs et ceux qui sont déjà habitués à une solution concurrente ;
diminuer le risque que l’utilisateur soit perdu ou frustré.
Si vous souhaitez apprendre comment garantir la cohérence de vos éléments d’UI UX design, lisez cet article.
2 – L’accessibilité de l’information
Comme dit plus haut, vos contenus doivent être parfaitement lisibles, aussi bien sur PC, tablettes et smartphones.
J’aime comment votre site web est impossible à lire sur mon smartphone
Voici les points à surveiller :
La taille de la police ;
Le contraste entre la couleur des textes et leurs arrière-plans ;
L’espace entre les paragraphes ;
La position des informations importantes.
3 – Est-ce que votre site transmet visuellement l’émotion que vous souhaitez ?
Votre image de marque et votre communication racontent une histoire à laquelle vos consommateurs décident de croire.
Mais pour qu’ils y croient, il faut que tous les éléments forment un tout cohérent.
Ok, jusque-là, c’est théorique et un peu philosophique.
Alors, on va prendre un exemple concret.
Imaginez un peu le site de votre banque classique aux couleurs joyeuses de McDonald’s. Bizarre n’est-ce pas ?
Clairement, vos attentes (fiabilité, expertise, confiance) ne matcheraient pas avec les émotions renvoyées par McDo (joie, fun, venez comme vous êtes).
Et qu’est-ce que vous allez faire ? Vous irez voir ailleurs.
C’est exactement la même chose avec vos prospects.
Si les visuels de votre plateforme ne correspondent pas à leurs attentes et à l’image qu’ils ont de votre marque… vous connaissez la suite.
8 – Examinez l’architecture de l’information
Good UX path vs Bad UX path
L’architecture de l’information représente la manière avec laquelle votre contenu est agencé.
Ça fait référence aussi bien au maillage interne entre vos différentes pages, qu’à la mise en page de chaque interface.
Ici, il n’y a qu’un seul mot d’ordre : vérifier que les informations de votre site soient présentées de manière claire, logique et facilement compréhensible.
Et si vous voulez aller encore plus loin, appliquez les lois UX suivantes :
La loi de Hick : plus le nombre de choix augmente, plus le temps de décision de l’utilisateur s’allonge et au final il ne fait rien. En conséquence, limitez toujours le nombre de choix par interface ;
La loi de Miller : l’être humain ne peut pas garder en mémoire plus de 5 ou 7 éléments. Ainsi, mettez toujours les éléments importants au début et à la fin de vos listes, jamais au milieu.
Maintenant que vous êtes armé de toutes les connaissances nécessaires pour auditer l’UX de votre site web, vous n’avez plus qu’une chose à faire : passer à l’action.
C’est le nombre de conversions que vous ratez lorsque votre app d’e-commerce n’est pas disponible dans la langue maternelle d’un segment d’utilisateurs 🥲 (source).
Et même si votre app est génialissime, il y a très peu de chances qu’un internaute aille apprendre une langue nouvelle juste pour l’utiliser.
Si vous souhaitez augmenter votre CA, une application bilingue, multilingue ou disponible dans toutes les langues est un atout de taille.
Et heureusement, traduire une application mobile est assez simple grâce à l’internationalisation.
L’internationalisation, ou i18N, consiste à concevoir des logiciels facilement adaptables aux différentes langues. Cerise sur le gâteau : l’i18N ne nécessite pas de modifier le code source de votre app.
Alors pourquoi s’en priver ?
On vous a concocté un guide complet sur comment traduire votre application à l’aide du framework i18N.
Let’s go.
Pourquoi i18N et pas une autre librairie d’internationalisation ?
Soyons d’accord : vous pouvez traduire automatiquement vos contenus avec un logiciel de traductionautomatique comme Google Traduction.
C’est rapide et pas cher.
Par contre, les résultats sont parfois assez douteux.
Raison pour laquelle les développeurs optent pour une autre solution : les frameworks React.
Il y en a deux :
React-intl
React-i18next.
Notre choix s’est porté sur l’outil de traduction React-i18next à cause de sa kyrielle d’avantages :
c’est une bibliothèque est intégralement écrite en JavaScript ;
React-i18N abrite un système de traduction automatique complet pour plusieurs langues différentes ;
c’est une bibliothèque aisément scalable grâce à sa capacité de séparer chaque traduction en plusieurs fichiers et de les charger à la demande.
Sans transition, voyons ensemble comment traduire votre application en plusieurs langues étrangères de A à Z.
5 étapes pour traduire intégralement les textes d’une application en plusieurs langues
1 – Installez les packages
Afin de traduire votre application mobile, vous aurez besoin d’installer tous les packages qui suivent :
I18N, la star du jour ;
React-i18n, qui vous permet d’utiliser toutes les fonctionnalités d’i18N dans votre application mobile react ;
I18next-browser-languagedetector, qui permet de détecter la langue de l’utilisateur depuis son navigateur ;
I18next-http-backend, que l’on utilisera pour charger les fichiers de traductions.
Pour les installer, rien de plus simple : copiez-collez la commande suivante dans votre invite de commande.
Vos textes à traduire ne seront pas rédigés directement dans le code source.
Vous pouvez le faire, mais c’est une très mauvaise idée.
À la place, voici ce qu’on vous propose : créer des fichiers pour chaque langue de traduction.
Suivez les instructions suivantes à la lettre pour que ça fonctionne :
Allez dans le répertoire « public » de votre app » ;
Créez-y un dossier « locales » ;
Pour chaque langue-cible que vous voulez intégrer, créer un nouveau fichier dans le dossier « locales ». Nommez chaque fichier selon les codes correspondants desdites langues (EN, FR, SP, etc.) ;
Enfin, dans chacun des dossiers de langues, créez un fichier « translation.json ».
Voici l’architecture que vous devriez normalement avoir :
Architecture fichier i-18next
3 – Initialiser i18next
Maintenant que les packages et les fichiers de traduction sont prêts, initialisons i18N.
Pour cela, créez un nouveau fichier i18n.js dans le répertoire src et ajoutez-y le code suivant :
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import LanguageDetector from 'i18next-browser-languagedetector';
import Backend from 'i18next-http-backend';
i18n
.use(Backend)
.use(LanguageDetector)
.use(initReactI18next)
.init({
debug: true,
fallbackLng: 'en',
});
exportdefault i18n;
Parmi toutes ces lignes, une est assez intéressante :
fallbackLng :’en’;
Concrètement, elle dit à l’application : « si tu ne trouves pas de fichier de traduction pour la langue de recherchée par l’internaute, affiche les contenus en anglais. ».
Sachant qu’un quart des internautes au monde comprennent l’anglais, c’est un choix judicieux d’en faire la langue par défaut.
Une fois que vous avez créé ce fichier, allez dans le fichier index.js, lui aussi situé dans le répertoire “src”. Rajoutez les lignes suivantes :
import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.css';
import App from './App';
import reportWebVitals from './reportWebVitals';
import './i18n'; // <--- add this
// ... other code ...
Grâce au composant « Suspense », nous allons pouvoir charger les traductions de manière asynchrone. Sans lui, si une ressource n’est pas disponible, votre app va afficher un vilain message d’erreur à l’utilisateur.
Ouvrez le fichier App.js et rajoutez les importations suivantes :
import { Suspense } from 'react';
import { useTranslation} from 'react-i18next';
// ...
‘T’ est la fonction que nous allons utiliser pour traduire nos textes.
‘I18n’ est l’objet que nous allons utiliser pour charger la liste des langues et les interchanger.
4 – Traduisons nos textes pleins avec i18N
Enfin, le moment tant attendu est arrivé : traduisons nos textes.
Pour ça, commencez (logiquement) par ajouter des traductions dans chacun de vos fichiers translation.json.
Voici comment faire avec la version anglaise.
{
"main": {
"header": "Welcome to the app!"
}
}
« header » ici est la clé de traduction que l’on va utiliser.
Si vous souhaitez traduire d’autres contenus, changez juste la clé et reprenez le même processus.
Refaite la même chose avec les autres langues et c’est bon.
Maintenant, il est temps de les utiliser.
Rien de plus simple : nous allons passer les noms des clés des textes à traduire à la fonction « t ». Au moment où le mobinaute voudra charger les contenus, ce sera la valeur de la clé qui sera affichée automatiquement.
Maintenant, allez dans le fichier src/App.js et ajoutez une traduction pour la balise h1 :
Ensuite, rebootez l’application en entrant la commande npm start dans votre invite de commande. Puis rendez-vous sur votre serveur local (http://localhost:3000) et vérifiez : tada, vos textes sont traduits.
Pour afficher la traduction de votre choix, allez dans le fichier i18n.js et ajoutez la commande :
i18n.changeLanguage('ES');
ES ici signifie espagnol. Mais si vous avez une autre langue en tête, remplacez ES par ladite langue.
Ça y est ! Vous venez de créer votre premier contenu traduit. Vous n’aurez plus qu’à insérer les traductions de chaque contenu dans les fichiers translation.js correspondants.
5 – Faire appel à une agence de développement web ou à des traducteurs freelances
Ok.
Vous savez maintenant comment traduire votre app.
Sauf que vous vous en doutez, si votre app comporte plusieurs interfaces remplies de textes… créer votre dictionnaire multilingue va vous prendre des mois.
Sans compter la gestion des balises 🤯
Vous avez 2 options :
soit vous mobilisez votre équipe pendant plusieurs semaines sur ça ;
soit vous faites appel à des traducteurs professionnels en freelance ou à une agence de développement web et économisez du temps.
3+1 Fails récurrents de traduction d’app à éviter à tout prix
Avant de nous séparer, parlons des menaces qui planent sur vos tentatives de traduction.
Et ils sont plus nombreux et plus vicieux que vous ne pouvez le croire.
On vous en a sélectionné les 4 plus dangereux.
1 – Oublier le formatage et la culture des pays visés
Aux USA, ils n’affichent pas le temps comme nous.
Tandis que nous sommes habitué·e·s au format jour/mois/années, les américains préfèrent le format jour/année/mois.
Pareil pour le calendrier. Pour nous, la semaine commence le lundi, contre dimanche chez l’Oncle Sam.
Pourquoi je vous parle de tout ça ? Pour vous mettre la puce à l’oreille sur les erreurs de formatage et de métriques.
Et elles ne concernent pas que l’heure. La monnaie, les fuseaux horaires, les unités de mesure… tout peut varier.
Ps : méfiez vous des règles de grammaire (You 🇬🇧 = Tu et Vous en français).
2 – Les symboles bizarres face aux caractères non latins
Vous les avez sûrement déjà vus.
Ces symboles qui ne veulent humainement rien dire, mais qui sont parfaitement logiques pour les logiciels.
C’est ce qu’il se passe quand vous essayez d’afficher des caractères non latins – chinois, hindi, arabe, etc. – avec un formatage purement latin (ex : ASCII).
Heureusement, la solution ici est assez simple : utilisez le format unicode autant que possible.
3 – Des boutons calibrés au millimètre
Dans notre article sur les 32 lois de l’UX design, on vous avait parlé des dangers de ne pas laisser de marge autour de vos contenus.
Et ça revient encore. Car si votre équipe de développement est anglophone et qu’elle prévoit des espaces adaptés uniquement à l’anglais, vous courrez à la catastrophe.
Pourquoi ? Parce que toutes les langues n’ont pas besoin du même nombre de mots/caractères pour exprimer la même idée.
Certaines, comme l’anglais, sont très concises. D’autres, à l’instar du français et de l’allemand, nécessitent beaucoup plus de caractères.
Fatalement, si ça n’a pas été pris en compte, vos textes vont déborder de vos éléments graphiques. Idem lorsque vos utilisateurs utilisent des extensions sur leurs moteurs de recherche pour vous comprendre.
Pour éviter ça, prévoyez toujours 30 % de marge autour des textes lorsque vous concevez la mise en page de vos interfaces.
4 – Des designs pensés pour une seule langue.
Vous lisez ce texte de gauche à droite.
Si je le traduis en japonais, vous ne le ferez plus de droite à gauche, mais de haut en bas. Et si j’opte pour l’arable, vous lirez de droite à gauche.
En conclusion : vérifiez toujours que vos textes traduits puissent être lus par toutes les audiences et dans tous les sens.
Je sais, vous auriez aimé avoir une réponse aussi précise.
Sauf que voilà, votre application est unique, elle est différente de toutes les autres.
Et son temps de développement l’est aussi.
Par conséquent, à défaut de pouvoir vous fournir une réponse exacte montre à la main, on a mieux à vous proposer : une estimation très précise de chaque étape de la création de votre application mobile.
Allez, on y va.
Pourquoi est-ce que la taille de votre application mobile compte ?
Saviez-vous que la première version d’Instagram a nécessité uniquement huit semaines de travail à ses développeurs ?
Interface de la première version d’Instagram
Vous pouviez poster des images, les partager, commenter et suivre d’autres utilisateurs. Il n’y avait pas encore certaines des fonctionnalités phares de l’app :
pas de réels ni de stories Instagram ;
aucune vidéo
pas de fil d’actualité algorithmique ;
À l’inverse, Spotify a pris presque deux ans pour (enfin) sortir sur les boutiques d’applications.
Pourquoi je vous parle de cela ? Pour vous rappeler que le premier paramètre dont dépend la durée de développement d’une application, c’est sa complexité.
Voici un petit guide (très) résumé pour vous aider à savoir dans quelle catégorie votre idée d’application se trouve :
Les petites applications mobiles : elles proposent des fonctionnalités simples et limitées, à l’instar de votre application de réveil ou la calculatrice de votre smartphone ;
Les applications moyennes : ce sont des apps qui ont des fonctionnalités plus élaborées, à l’instar des réseaux sociaux, des jeux et des lecteurs de musique. Comment les reconnaître ? C’est simple : elles raffolent des interactions avec les utilisateurs, de l’intégration des services externes (API) et s’appuient souvent des bases de données vastes ;
Les grandes applications : il s’agit d’applications proposant un très vaste panel de fonctionnalité – paiements, géolocalisations, capteurs, notifications push, design personnalisé, etc. Les applications d’e-commerce en sont les meilleurs exemples.
Fun fact : plus votre application est complexe, plus vous devrez prévoir du temps pour des aspects non-techniques et souvent oubliés.
Communication, gestion d’équipe, planification et gestion entre autres.
Maintenant que c’est dit, intéressons-nous aux différentes étapes du processus de création d’une app.
Les 5 phases typiques du processus de développement d’une app mobile (+ leurs temps respectifs)
Étape 1 : Rédiger le cahier des charges de votre application mobile
Avant de coder votre application, encore faut-il savoir avoir une idée précise du service digital à créer.
Quelles fonctionnalités doivent être présentes au sein de l’app ?
Qui seront les clients cibles ?
Quel problème allez-vous résoudre ?
Quel est l’état du marché dans lequel vous souhaitez vous lancer ?
Quelles sont les contraintes et les spécifications techniques auxquelles votre application devra faire face ?
Quelle sera la stratégie de lancement de votre application ?
Sur quel système d’exploitation mobile allez-vous la déployé ? iOS ? Android ? Les deux ?
Bref, comme tout projet, vous allez devoir consacrer beaucoup de temps à la planification de votre app.
Comptez entre 2 et 6 semaines au moins pour cette étape.
Étape 2 : Designer toutes vos futures interfaces (et n’essayez pas de prendre des raccourcis)
L’une des meilleures décisions que vous puissiez prendre pour réussir votre projet, c’est d’engager des UI/UX designer dès le début.
Pourquoi ? Pour au moins 3 raisons :
ils vous permettront d’avoir des wireframes et des prototypes rapidement, ce qui vous permettra de tester votre idée d’application avant d’avoir codé 1 ligne ;
ils repèrent les erreurs d’UX, notamment dans les flux utilisateurs et les parcours utilisateur ;
enfin, des experts en UX/UI sont les seuls à pouvoir vous créer une interface belle, ergonomique et tendance.
Et si vous croyez qu’on exagère ou que l’on prêche pour notre paroisse, détrompez-vous : le marché des applications mobiles se base surtout sur le visuel.
Si votre UI design est moche, les utilisateurs vont déguerpir moins de cinq secondes après l’avoir téléchargé.
Pareil si l’expérience utilisateur est bancale et/ou ponctuée de points de friction.
Que l’architecture de l’information est incompréhensible.
Ou qu’il faut un tutoriel pour comprendre quel élément graphique fait quoi.
Et encore une fois la complexité de votre idée – qui se répercute sur les interactions et la quantité de contenus.
Et surtout : n’essayez pas de commencer à programmer avant d’avoir fini cette étape.
Car sans vos prototypes finaux, la documentation de votre projet sera incomplète.
Étape 3 : Développer l’application mobile
C’est à ce moment que vos talents en programmation (ou ceux de vos équipes) entrent en jeu.
Le codage de l’application est clairement l’étape la plus longue.
Elle dure entre 4 et 24 semaines.
Pourquoi cet écart ? Eh bien pour plusieurs raisons :
L’OS mobile sur lequel vous allez déployer votre app : sachez que les applications hybrides faites sur React native ou Flutter prennent moins de temps que les app natives programmées en Swift/Kotlin ;
Votre choix de développer soit une application hybride, soit une progressive web app (PWA) soit une application native pour Android et iOS : si vous faites une app pour chaque os, vous allez devoir créer deux applications mobiles distinctes (et ça prend plus de temps).
Bien sûr, le nombre de fonctionnalités et leur complexité comptent aussi pour beaucoup.
Étape 4 : Tester l’application mobile
L’une des erreurs à ne pas commettre, c’est de lancer votre application sans l’avoir testée.
Dans l’idéal, vous avez construit un MVP lors de la phase précédente et l’avez amélioré à chaque itération selon les feedbacks utilisateurs.
Mais si ce n’est pas le cas, alors armez-vous d’un groupe de testeurs qui vont… tester votre app.
Chaque fonctionnalité.
Chaque élément de l’UI.
Tous les boutons.
Le flow utilisateur.
Tout doit être passé au crible, sinon gare aux retours négatifs qui vous accueilleront sur l’App Store et le Google Play Store.
Pour que vos testeurs puissent valider tous les scénarios, prévoyez entre 2 et 4 semaines.
Étape 5 : Lancer l’application mobile
Avez-vous déjà entendu parler de l’ASEO (App Store optimization) ?
Si votre réponse est non, sachez qu’il s’agit des techniques à utiliser pour que votre application soit mieux classée sur les boutiques d’applications.
Car le marché des applications mobiles est un marché féroce et concurrentiel, vous ne pouvez pas vous permettre d’être mal référencé.
De plus, vous allez aussi devoir investir du temps et de l’énergie pour faire la communication autour de votre produit.
Idem pour engager et fidéliser une audience autour de votre écosystème.
Enfin, votre équipe de modération devra anticiper (et gérer) les feedbacks négatifs des utilisateurs mécontents.
Autant dire que cela vous prendra beaucoup de temps.
Comptez entre 1 et 3 semaines pour rendre vos applications téléchargeables depuis les magasins d’applications.
3 facteurs qui vont ralentir le développement de votre app mobile (voire le faire échouer)
Sans transition, voici trois éléments que vous devez à tout prix éviter sous peine de rallonger le délai de développement.
1 – les changements imprévus (ou pourquoi un cahier des charges précis est capital)
2011.
Si je vous parle d’un réseau social destiné au partage massif de photos et de vidéos, à quelle app pensez-vous ?
Probablement à Instagram de Meta.
Oui, mais Instagram a été une réussite.
Ce qui n’a pas été le cas d’une startup rivale qui visait le même créneau : Color Labs.
Logo de l’application color Lab
Color Labs a été fondé par Bill Nguyen en 2010 à Palo Alto.
Silicon Valley Bank, Sequoia Capital, Bain Capital et d’autres mastodontes du capital-risque ont investi 41 millions de dollars dans le projet.
Et deux ans plus tard, Color Labs a été revendu à Apple pour « à peine » 7 millions de dollars.
Comme quoi, même avec 41 millions de dollars en poche, une équipe IT composée de la crème de la crème de la Silicon Valley… le succès n’est pas garanti.
Alors pourquoi je vous en parle ?
Tout simplement parce que la raison du fiasco de cette startup tech n’était ni technique ni financière.
Elle résulte à des changements trop fréquents de la part de son chef de projet et fondateur, Bill Nguyen.
Tantôt réseau social de partage de photos entre utilisateurs géographiquement proches.
Tantôt plateforme de live streaming.
Affiche publicitaire pour Color
Color Labs n’a jamais vraiment été compris par ses utilisateurs (ni par ses investisseurs).
Et de l’incompréhension au bouton de désinstallation, il n’y a qu’un pas qu’ils ont vite franchi.
Alors s’il vous plaît, fixez-vous un cap et un cahier des charges et tenez-vous-y.
On l’a vu, construire une application peut prendre en quelques semaines et un an.
Alors lorsque l’on tente de raccourcir les délais en se fixant des objectifs irréalistes… le dépassement de délai et l’explosion de budget ne sont jamais loin.
Au final, combien de temps devez-vous prévoir pour la création de votre app
Ok.
Une fenêtre d’estimation entre trois mois et un an ne vous avance pas beaucoup.
Et impossible de faire un guide détaillé qui vous fournira une réponse précise à la minute près.
Vous avez déjà listé ses futures fonctionnalités, avez même déjà pensé à comment la monétiser.
Mais si vous êtes ici, c’est que vous faites face à un gros, très gros problème : vous n’avez pas encore une équipe de développement sous la main. Et surtout, vous ne savez pas exactement de quels experts et spécialistes vous avez besoin.
N’est-ce pas ?
Raison pour laquelle aujourd’hui, on va vous montrer les profils indispensables à votre équipe de développement d’applications + 3 manières de la créer.
Mais avant…
Pourquoi est-ce que faire appel à un seul développeur ne suffira pas pour créer votre application mobile
Ce n’est un secret pour personne, les logiciels ne sont que des amas de code.
Logiquement, si vous engagez un excellent programmeur, ça devrait faire l’affaire… Sauf que non.
Pour de petits projets personnels ou la création de site d’e-commerce basique, un seul programmeur peut faire l’affaire.
Par contre, dès que vous voulez développer une application mobile interactive avec des éléments complexes – GPS, réalité virtuelle, analyse de données, capteurs, IA, publicités in-app, etc. –, c’est autre chose.
Vous aurez besoin d’une équipe.
Et pas seulement d’une équipe de développeurs mobiles aguerris.
6+1 profils qu’il vous faut obligatoirement dans votre (future) équipe de développement
Sans transition, voici les expertises dont vous aurez besoin pour créer une équipe de développement d’application mobile efficace :
1 chef de projet informatique ou 1 product manager
1 stratège marketing ou 1 business analyst
1 ou plusieurs développeurs front-end
1 ou plusieurs développeurs back-end
1 ou plusieurs UX/UI designers
1 ou 2 ingénieurs en assurance qualité
(facultatif) 1 architecte logiciel
Voici typiquement les experts qu’il vous faut. En fonction de vos besoins, vous pouvez aussi avoir besoin d’autres spécialistes, tels que les devOps, les scrum masters, etc.
Comment les personnes des équipes IT se voient mutuellement
Mais restons sur les profils “essentiels”.
Voyons précisément à quoi chacun d’entre eux vous servira.
1 – Le chef de projet informatique / product manager
Le chef de projet informatique ou product manager a une double fonction :
veiller à ce que votre projet d’application soit réalisé en respectant les délais, votre budget et le cahier des charges ;
assurer la communication entre l’équipe de développement et la maîtrise d’ouvrage (vous).
C’est donc un excellent communicateur et qui maîtrise les technologies nécessaires pour donner vie à votre idée.
Ce sera d’ailleurs le premier membre de votre équipe que vous embaucherez. Toutefois, sachez que tous les chefs de projets informatiques n’ont pas les mêmes rôles.
Car derrière ce titre, se cache souvent deux métiers totalement différents : les projects managers et les products managers.
Lorsque l’équipe est suffisamment grande – et que votre budget vous le permet -, ces deux rôles sont séparés. Par contre, il n’est pas rare qu’ils soient assumés par la même personne.
Les project managers
Le project manager se focalise sur un et un seul projet.
Plus exactement, sa préoccupation principale se trouve au niveau des performances de l’application en cours de développement.
Il se pose des questions du type :
Est-ce que le processus de développement est respecté ?
Quelles sont les tâches à prioriser lors du prochain sprint ?
Est-ce que la documentation du code est exhaustive ? Est-ce que quelqu’un d’externe à l’équipe peut la lire et la comprendre ?
Quel membre de l’équipe fait quoi ?
Passons au product manager.
Les Products managers
Contrairement au gestionnaire de projets, le product manager se focalise sur un produit, et non sur un projet.
Ça signifie que lorsque le développement sera terminé, il restera là pour travailler avec vous. Il vous aidera en plus à atteindre des objectifs qui ne sont pas purement techniques.
Voici quelques questions qu’il se posera :
Est-ce qu’il y a un marché favorable pour votre concept d’application ?
Quels types d’utilisateurs peuvent être intéressés par votre (futur) produit ?
Quelles seront les fonctionnalités principales de l’app ?
Pourquoi vos cibles potentielles la téléchargeront sur les magasins d’applications ?
Quels paints points allez-vous résoudre ?
Quelle est votre USP, votre proposition de valeur unique, et comment la mettre en avant via un call to action puissant ?
Quels segments de marché seront les plus rentables ?
Comment allez-vous monétiser votre application ?
Bref, vous l’avez compris, le product manager est un passionné de business plan et d’analyses de marchés.
De plus, dès que votre app sera déployé, il analysera vos premiers feedbacks.
Ses objectifs : trouver ce que les mobinautes adorent sur l’application et ce qu’ils détestent, puis corriger le tir si nécessaire.
2 – Le stratège marketing + 1 business Analyst
En fonction de la complexité de l’application – et de votre budget -, vous avez trois alternatives :
soit n’embaucher qu’un chargé de marketing digital qui va se charger de toute la communication et du lancement de l’application ;
ou embaucher un business analyst qui va monitorer en permanence les résultats de vos campagnes et les actions de vos utilisateurs ;
soit faire appel aux deux types d’experts.
Peu importe votre choix, la personne ou l’équipe en charge de ce poste fournira au moins les 3 services suivants :
la gestion de l’ASEO – l’optimisation des métadonnées de votre application mobile sur les magasins d’applications. Sans ça, votre application sera mal classée sur l’app store d’Apple et sur le Google Play Store. Votre nombre de téléchargements en prendra un coup ;
le suivi et l’analyse des résultats de vos actions marketing ainsi que des comportements des utilisateurs sur vos interfaces ;
la mise sur pied de stratégies marketing et de modifications à apporter à l’app pour augmenter votre ROI.
Sans transition, passons au prochain expert dont vous aurez besoin.
3 – Le ou les développeur(s) front-end
Tous les développeurs n’ont pas les mêmes rôles.
Nope.
En réalité, ils peuvent être regroupés en 3 catégories distinctes :
les développeurs front-end, qui se chargent de créer les fonctionnalités de l’application, de coder les interfaces que l’utilisateur verra, d’optimiser le SEO de l’app… Bref, il gère toute la partie « client » de l’app ;
les développeurs back-end, qui se chargent de la partie serveur de votre logiciel, des protocoles d’échanges de données entre vos serveurs et les périphériques de vos utilisateurs. Ainsi que le stockage des données dans le cloud.
enfin, les développeurs full-stack, qui maîtrisent tous les outils et langages nécessaires pour faire les deux.
Peu importe la complexité de votre projet, vous aurez besoin d’au moins un développeur front-end. Pour les reconnaître, jetez un œil aux langages de programmation et aux frameworks qu’ils maîtrisent.
En voici quelques-uns :
les langages de programmation JavaScript, HTML, CSS
quelques frameworks et librairies : React Native, Jquery, Angular, etc.
Et la liste n’est pas finie.
Sur quelle(s) plateforme(s) allez-vous déployer votre application ? Android ? iOS ? Les deux ?
Est-ce que ce sera une application native (c-a-d développée pour un seul système d’exploitation) ?
Ou cross-plateforme ?
Normalement, vous devriez avoir la réponse dans l’étude de marché faite par votre product manager.
les développeurs iOS, maîtres des langages de programmation Swift et Objective-C ; de l’IDE Xcode et très fins connaisseurs du très sévère « Apple Human Interface Guidelines ».
les développeurs Android, qui maîtrisent plutôt les langages Kotlin et Java, ainsi que l’environnement de développement Android Studio ;
Imaginez un instant que votre application soit un restaurant…
Les clients commandent les plats et se les font apporter via des serveurs. Ça, c’est la partie front-end.
C’est ce que vos consommateurs voient.
Mais ce ne sont pas les serveurs qui préparent les plats. C’est le chef cuisinier et son staff.
Même s’ils sont invisibles aux yeux des clients, c’est bel et bien eux qui font tourner le restaurant. C’est la partie back-end.
Et dans le cadre du développement d’applications mobiles, ce sont les développeurs back-ends qui se chargent de cette partie.
Différences entre développeur full stack vs back end vs front end
Comme dit plus haut, ce sont eux qui mettent en place la logique opérationnelle de votre app. Et qui veille à ce que l’échange de données entre toutes les entités se fasse de manière fluide et en toute sécurité.
En cas de manque d’effectifs, les développeurs back-end se chargent aussi de faire les tests sur le logiciel.
Pour en reconnaître un, c’est assez simple, regardez s’il maîtrise l’une des compétences suivantes :
les langages de programmation orientés serveur : Python, PHP, Ruby, SQL, etc. ;
les frameworks et librairies dédiées aux serveurs web : Nest.js, Node JS ou Express JS pour ne citer que ceux-là – on vous a d’ailleurs fait un article qui explique les différences entre Node.JS et les autres ;
des systèmes de gestion de bases de données (SGBD) : MariaDB, MongoDB, MySQL, Microsoft SQL Server ;
le système d’exploitation Linux et les commandes bash.
Maintenant, passons au prochain profil.
5 – L’UX/UI designer
L’UX/UI designer est un mélange de deux fonctions :
l’UX designer, un maître des 32 lois de l’expérience utilisateur qui veille à ce que vos mobinautes vivent une expérience inoubliable sur vos interfaces ;
l’UI design, plus tourné vers la beauté que la fonctionnalité et qui connaît par cœur les principes du webdesign.
Voici les missions qu’un UX/UI designer fera pour vous :
il créera étape par étape les différents parcours utilisateur et éliminera (ou pas) tout point de friction ;
en collaboration avec le développeur front-end, il concevra les interfaces et les widgets de votre app ;
peaufinera votre user persona – qui est différent du buyer persona que fourni par votre chef de projet ;
Si votre chef de projet le juge nécessaire – et que votre budget vous le permet – n’hésitez pas à prendre deux profils spécialisés. L’expérience-client proposée par votre plateforme sera bien meilleure (et vos clients plus heureux).
Pour bien voir l’utilité de chacun, voyons-les plus en détail.
Meme sur la différence entre la conception UI et la conception UX
L’UX designer
Son principal objectif : faire que vos utilisateurs vivent une expérience inoubliable sur vos plateformes.
Contrairement à l’UX design qui mise sur la beauté des interfaces, l’UX quant à elle s’intéresse à un autre élément : l’usabilité, ou facilité d’utilisation.
Pour citer le site web Interaction Design Foundation : « La facilité d’utilisation est une mesure de la capacité d’un utilisateur spécifique, dans un contexte spécifique, à utiliser un produit/concept pour atteindre un objectif défini de manière efficace, efficiente et satisfaisante. ».
L’UX designer prend énormément en compte la psychologie humaine et les comportements des utilisateurs. Grâce à ça, il conçoit des flux utilisateurs sans friction – sauf s’il estime qu’un point de friction est nécessaire – et qui vont créer une expérience utilisateur inoubliable.
Voici quelques missions qu’il va réaliser pour vous :
la définition et la construction de votre branding ;
l’amélioration de l’utilisabilité de l’app ;
le listing des fonctionnalités à ajouter/retirer pour augmenter la satisfaction utilisateur ;
un peu de webdesign ;
une recherche approfondie sur vos consommateurs et vos concurrents ;
enfin, c’est lui qui définit comment les informations seront organisées au sein de l’architecture d’information.
Il utilise exactement les mêmes outils listés plus haut, les cartes mentales en plus.
L’UI designer
L’UI designer est un Picasso 2.0 dans l’âme.
Centré sur l’utilisateur, il cherche à concevoir des interfaces interactives aux graphismes les plus irréprochables.
Tandis qu’un UX designer se contentera d’indiquer l’emplacement d’un élément – un bouton par exemple-, l’UI designer choisira le reste. Sa couleur, son style, ses effets visuels, son comportement lorsque l’utilisateur clic dessus ou le survole, etc.
Concrètement, voici ce qu’il fera pour vous :
il créera des layouts de toutes vos pages pour les rendre plus interactives ;
supervisera aussi la rédaction des contenus textuels de vos pages
le benchmarking graphique ;
définira les éléments visuels de votre branding (guideline visuel, création de logo, choix de la palette des couleurs, choix des polices, styles d’images, etc.).
Sans transition, passons au prochain profil.
6- L’ingénieur en assurance qualité
Septembre 1999.
125 millions de dollars.
Prononcez ces deux phrases devant un passionné d’espace, et vous lirez de la tristesse dans ses yeux.
Les calculs étaient bons. La trajectoire parfaite. Les matériaux irréprochables.
Bref, la NASA avait tout bon… mais elle s’est planté à cause d’une erreur banale sur les métriques.
Car, voyez-vous, le projet a été réalisé par deux entreprises : une utilisant le système métrique pour ses mesures (kilogramme, kilomètres, etc.) et l’autre, le très compliqué système impérial américain (livre, pounds, miles, yards et j’en passe).
Résultat : la sonde spatiale ne comprenait plus ses propres données… et vous connaissez la suite.
Tout ceci aurait largement pu être évité si la NASA avait fait appel à un ingénieur assurance-qualité.
En plus de vous faire économiser beaucoup d’argent en frais de réparation – sans compter la protection de votre image de marque -, un ingénieur QA a pour rôle de :
vérifier que le produit répond bel et bien à toutes les spécifications de son cahier des charges ;
veiller à ce que le livrable finale soit de la plus haute qualité en contrôlant ses progrès et en repérant les bugs passés sous le radar des devs au fur et à mesure ;
tester et écrire tous les scénarios de tests.
Côté outils, attendez-vous à ce qu’il maîtrise des outils comme Jira, TestComplete ou Appium.
7 – L’architecte logiciel
Si votre équipe n’est pas très grande, celui-ci est facultatif.
Son rôle consiste à établir des normes de codage, choisir les plateformes et les outils à utiliser. Il n’est d’ailleurs pas rare que le chef de projet endosse ce rôle.
C’est donc un fin communicateur, un maître de la gestion des ressources humaines et quelqu’un de doué pour faire des prévisions financières.
8 – Bonus : un conseiller juridique ou un avocat spécialisé en droit des logiciels
L’une des pires choses qui puissent vous arriver n’est pas d’échouer le lancement de votre application.
Ni de ne pas réussir à mener son développement au bout.
Non.
C’est de réussir à la monétiser, d’en tirer des revenus conséquents… puis de voir une légion d’avocats sonnés à votre porte, vous expliquant que vous devez payer des frais pour la propriété intellectuelle.
Tout comme l’assurance-qualité, la question de la propriété intellectuelle d’une application est souvent oubliée par les propriétaires d’applications web et mobiles.
Parce que oui, l’idée de l’application vient de vous, vous avez financé son développement à 100 %… Mais vous n’êtes pas forcément le propriétaire de tous les droits moraux et patrimoniaux du livrable final.
Du moins aux yeux du Code de la propriété intellectuelle.
Un conseil : si l’une personnes que vous voulez intégrer à votre équipe, ou l’agence web, refuse de signer un accord de transfert de propriété intellectuelle, fuyez.
Vos avocats vous diront que vous avez un excellent choix.
2 astuces pour trouver les team members fiables et efficaces
Homme assis devant son ordinateur
Maintenant que vous savez de qui vous avez besoin, comment est-ce que vous allez les trouver ?
En naviguant sur les plateformes ou sur le web, vous trouverez des légions de freelances et d’agences webmarketing.
Et aussi d’innombrables histoires d’horreurs de personnes ayant fait appel à des prestataires.
Alors pour éviter que vous ne deveniez un des nombreux auteurs des forums de réclamations contre des prestataires, suivez ces deux conseils.
1 – Ne cédez pas aux sirènes des bas coûts : cherchez des experts qualifiés
pouce tendu vers le bas
Ça peut être tentant de vouloir faire des économies en optant pour des partenaires peu chers – et très souvent offshores.
Oui, mais voilà, le moins cher est toujours cher. Et une application ne se résume pas qu’à un amas de code mélangé à des éléments graphiques.
Car pour créer un logiciel, le tout n’est pas d’avoir des rudiments de codage informatique.
La communication, la réglementation, les performances du produit final, l’accompagnement… autant de choses que seuls des prestataires expérimentés peuvent vous garantir.
Et qui comptent pour beaucoup dans la réussite de votre projet.
2 – Vérifiez systématiquement les références de vos potentiels partenaires
Dans les portfolios et les CVs que vous recevrez, soyez toujours attentif aux références marquées.
N’hésitez pas à chercher le nom de la compagnie mentionnée sur Google et à passer un coup de fil pour avoir le cœur net.
Aucun doute : vous serez parfois surpris, désagréablement.
De plus, si vous recrutez via une plateforme type Upwork ou Fiverr, prenez les avis clients sous les profils avec des pincettes. Il n’est pas rare que des agences et des freelances s’échangent des avis positifs.
Même son de cloche si vous trouvez votre agence via votre moteur de recherche. Scrutez attentivement les avis laissés sur la page Google My Business de ladite agence. Ensuite, piochez-en quelques-unes et passez des coups de fils.
3 façons de construire la dream team pour le développement de votre application mobile
Selon vos besoins, vous pouvez opter pour 3 modèles différents de collaboration avec les membres de votre équipe de développement :
embaucher vos collaborateurs en tant qu’employés à temps plein ;
faire appel à des freelances via des plateformes comme Malt ou Fiverr ;
déléguer la création de votre application mobile à une agence de développement web.
Allez, voyons tout de suite les avantages et les inconvénients de chacun de ces modes de fonctionnement.
1 – Embaucher des spécialistes en tant qu’employés à plein temps
Si vous optez pour cette option, alors, you are the boss.
Ni plus ni moins.
CEO, fondateur, PDG… Cette option vous propulse dans cette catégorie.
Hormis le prestige, embaucher des experts IT à temps plein à son lot d’avantages :
vous avez une équipe dédiée à votre projet et qui ne travaille que sur votre projet ;
vous obtenez le contrôle total sur la propriété intellectuelle de votre future application ;
la confidentialité des informations stratégiques est optimum.
Par contre, ça a ses inconvénients :
c’est le mode de collaboration le plus cher de tous parce que vous devez payer un loyer, des équipements informatiques, des logiciels hors de prix, des taxes, des cotisations sociales et d’autres impôts que vous ne voulez pas payer ;
si vous n’êtes pas familier avec le processus de recrutement, vous allez vite déchanter, tant c’est difficile ;
le projet va débuter très lentement.
Clairement, cette option n’est valable que si vous avez plusieurs projets sur lesquels vous voulez travailler à la suite.
Sans compter les milliers d’euros que vous devez avoir en réserve pour honorer vos obligations. Et ce même si votre application ne génère pas de revenus immédiats.
2 – Faire appel à des freelances
Femme devant son PC face à la plage
Faire appel à un prestataire externe a plusieurs avantages :
vous ne le payez que lorsque vous avez besoin de ses compétences ;
il s’adaptera très rapidement à vos nouveaux projets ;
vous avez un vaste choix de prestataire et pouvez accéder à des talents situés à l’autre bout du monde.
Toutefois, avant de vous ruer à la conquête de vos freelances, prenez en compte les inconvénients qui vont avec :
si vous optez pour un freelance offshore, vous êtes exposé à un flou juridique ;
vous ne serez que rarement sa priorité vu qu’il alternera entre plusieurs projets ;
ce mode de fonctionnement marche difficilement pour des projets complexes ;
les risques de fuites de données seront accrus ;
vous serez exposé à des problèmes de communication, surtout si vous parlez des langues différentes.
Logo de GraphQ
