Bonjour, je suis développeur web chez Uxer depuis plus de 2 ans, et cela fait 3 ans que j'en ai fait mon métier. J'ai toujours bidouillé du code par passion. Avant ça, j'ai fait une école de commerce et des études en informatique, science des technologies et développement durable. J'ai 27 ans et j'habite à Bordeaux.

Comment vois-tu l'IA de manière générale ?

De manière générale, je vois l'IA comme une nouvelle ère dans la technologie des outils. Que ce soit pour le quotidien, dans le travail ou dans la vie de tous les jours : une utilisation pas forcément poussée à son paroxysme, mais utilisée pour des usages très spécifiques, via de petites mécaniques invisibles pour l'utilisateur, mais également dans la communication des entreprises (génération de contenus et de visuels publicitaires).

J'y vois également des côtés négatifs évidents, notamment d'un point de vue artistique, entre l'art créé par des artistes et les contenus générés par des ordinateurs, mais aussi avec l'invasion dans la vie privée, puisque l'IA utilise essentiellement nos informations pour apprendre, générant de premières polémiques : comme lorsque l'IA est activée par défaut dans les services que nous utilisons, sans demande préalable à l'utilisateur… !

Nous avons atteint une certaine maturité qui engendre ce type de problèmes. Il nous faut les résoudre jusqu'à trouver la bonne mesure, même si je ne pense pas que nous finirons comme dans Terminator avec Skynet ! J'ai la conviction que ce serait rejeté par les utilisateurs et la population, qui refuserait les dérives.

Quoi qu’il en soit, nous sommes clairement à un tournant. Des solutions plus ouvertes comme Deepseek (Chine), également Mistral (Europe) viennent concurrencer les géants américains, et apporter une vision différente de l'usage des IAG. C’est une bonne nouvelle pour tous.

Utilises-tu l'IAG (Intelligence Artificielle Générative) dans ton métier ? Si oui, comment et pourquoi ?

Oui, j'utilise l'IAG quotidiennement, avec plusieurs cas très précis : dans mon éditeur de code tout d’abord, lorsque je crée une fonction, l'IAG va me proposer des solutions pour terminer ma fonction, avec un gain de temps notable. Également, pour importer des composants, et des modules dans mon code, l'IAG va me proposer des solutions en fonction de mes habitudes, afin d'exécuter mes tâches répétitives tout en améliorant ma qualité de vie au travail.

J'utilise également le tchat de l'IAG lorsque je dois solutionner des dysfonctionnements. Je l'interroge sur l'erreur que je rencontre, et j'obtiens des réponses plus rapidement, notamment sur des Frameworks comme Next.js. La nature des erreurs peut parfois être complexe à déchiffrer, j’évite ainsi de chercher pendant des heures. L'IAG vient me simplifier la compréhension de l'erreur en la synthétisant et en déchiffrant les ressources disponibles pour tenter de résoudre les bogues.

Enfin, j'utilise l'IAG également pour structurer mes idées et mon code. Je soumets alors les bases de ma réflexion et l'IAG me propose une vision complémentaire de l'organisation prévue de mon code, pour en optimiser les performances - j'utilise ensuite les recommandations ou non. L'IAG m'apporte également des clarifications utiles en complétant les ressources et la documentation de base avec les nombreux retours d'expériences présents sur le web.

De fait, l'IAG apporte un gain de temps notable qu’il me serait difficile d’ignorer aujourd’hui. Sans cela, il me faudrait de 1 à 2 heures de plus par jour pour faire la même chose. J'obtiens également des réponses bien plus rapidement que si je devais opérer des recherches manuelles sur le web et attendre parfois une réponse plusieurs jours, alors que je peux l'obtenir quasi immédiatement avec l'IAG.

Vois-tu une évolution de ton métier depuis que l'IAG est présente au sein des outils ?

Oui, pour le résumer : avec l'IAG, on peut se permettre des fonctions plus complexes et optimiser les performances, tout en conservant la même contrainte de temps.

L'agence avait émis un avis de prudence sur l'utilisation de l'IAG, notamment dans le cadre des travaux menés pour nos clients, peux-tu décrire ce cadre ? Cela a-t-il influencé ton utilisation ?

Pour ma part, je n'ai jamais utilisé l'IAG pour générer du code que je ne comprenais pas, c'était essentiellement ce risque qu'il s'agissait d'appréhender pour permettre une pleine maitrise de son travail. Mon éditeur de code m'accompagne dans la création du squelette, de la structure du code que je produis. J'utilise l'IAG pour résoudre des bogues, afin d'accéder à plus de documentation et plus vite, mais je reste maître de ma solution.

Au sein de l'agence, nous mettons régulièrement à jour les versions du code que nous créons, mais aussi nous aimons créer nos propres packages de code, en regroupant des fonctions spécifiques pour optimiser les appels vers les différents services utilisés. Dans ces cas, nous trouvons des limites claires dans l'usage des IAG qui deviennent inopérantes dès que nous sortons des sentiers battus. Cela suppose que nous restions autonomes et très compétents sur nos métiers.

Comment vois-tu l'avenir de ton métier, et plus généralement l'avenir à travers le prisme de ces avancées technologiques ?

C'est la grande question. De mon avis, l'IAG ne me prendra jamais mon travail, bien qu'elle le transforme, car l'IAG a besoin de développeurs et de la grande quantité des informations que nous générons pour créer ses propres solutions et nous les soumettre par la suite.

Combien de fois nous rencontrons le cas où un projet que nous codons part dans une direction inattendue, pour de multiples raisons (choix du donneur d'ordres, nouvelles idées, ajustement du marché, etc.) ! L'IAG trouve là encore ses limites. Dans ces cas, elle se perd rapidement et il faut quasiment autant de temps, voire plus, pour obtenir une réponse fiable de sa part. Il vaut mieux alors la trouver par nous-mêmes.

Je trouve ainsi des limites indépassables à l'IAG, du fait de la nature humaine plastique alors que l'IAG n'aura certainement jamais cette plasticité. C'est une bonne chose !

Seule une IA générale (à différencier d'une IA générative) pourrait dépasser ce paradigme : si nous en arrivons un jour à ce cas-là, il y aura alors effectivement énormément de jobs qui disparaitront (le mien compris) et certainement aussi une importante crise sociétal et économique pour nous obliger à repenser notre vision du travail et de la vie. D'autant que je doute que ce type de technologie ne soit utilisé que pour de bonnes raisons.

Nous nous trouvons clairement à un tournant technologique, qui effectivement peut nous amener plus loin tout en questionnant notre vision de l’humain dans son environnement de vie et de travail. Reste à savoir ce que nous souhaitons en faire.

Rémi, développeur fullstack chez Uxer, répond à nos questions sur l'IA et sur son utilisation au sein de l'agence

Nous avons choisi d'y répondre en donnant la parole à celles et ceux qui l'utilisent chaque jour : notre équipe. Aujourd'hui, c'est Rémi, développeur fullstack chez Uxer, qui répond à nos questions sur l'IA, et sur son utilisation au sein de l'agence.

Comment notre développeur Rémi utilise-t-il l'intelligence artificielle au quotidien chez Uxer agence digitale ?

Lancer un nouveau produit sur le marché est un défi complexe qui nécessite de jongler avec de nombreux facteurs : comprendre les besoins des utilisateurs, évaluer la concurrence, gérer les ressources financières et techniques, s'adapter rapidement...

Les méthodes pour aborder ce challenge sont variées. Par exemple, le développement en cascade ou "Waterfall", consiste à suivre un processus linéaire et structuré, mais peut manquer de flexibilité pour s'adapter aux changements. D'autres approches, comme le Lean Startup et le Design Thinking, mettent l'accent sur l'expérimentation et l'empathie utilisateur, tandis que de nombreuses autres méthodes issues de la pratique agile favorise des itérations rapides et une collaboration constante pour ajuster le produit en temps réel.

Parmi ces approches, le Minimum Viable Product (MVP) se distingue par sa capacité à valider rapidement une première idée et direction de produit avec un minimum de ressources.

Dans cet article, je vous propose de décortiquer ensemble la notion de MVP. 🚀

Commençons par une rapide définition. Le MVP est une version simplifiée d'un produit, dotée de fonctionnalités limitées mais jugées essentielles pour satisfaire les premiers utilisateurs. Il se concentre sur l'apprentissage rapide et l'adaptation par itérations successives, minimisant ainsi les risques d'échec.

Vous souhaitez par exemple construire une voiture. Vous auriez par instinct peut-être envie de construire le moteur, puis monter les roues, assembler la carrosserie…

Si l’on suit plutôt une logique de MVP, l’idée sera dans un premier temps de mettre en place une version minimale qui permet de répondre au besoin principal de vos utilisateurs, ici se déplacer. Nous pourrions commencer avec un skate. Puis on évoluera, au fil des observations et des retours, vers une trottinette, un vélo, un scooter et enfin une voiture.

Le principal avantage d'un MVP est qu'il permet de tester rapidement une idée de produit auprès de vrais utilisateurs. Cela aide à vérifier si le produit répond vraiment à un besoin (le besoin de se déplacer dans ce cas d’exemple), et à ajuster la prochaine version (une superbe trottinette) en fonction des retours sur le produit.

En limitant le développement initial aux fonctionnalités critiques, un MVP diminue le risque de surdévelopper un produit qui pourrait ne pas trouver son marché.

Il permet aussi une adaptation rapide en fonction des retours des utilisateurs. Les équipes peuvent ainsi itérer rapidement, ajoutant ou modifiant des fonctionnalités en fonction des besoins réels, ce qui améliore la pertinence du produit final.

La démarche peut sembler plus longue, mais elle est surtout plus sûre que le fait de lancer un produit complexe dès le départ.

L’intérêt est de construire de manière itérative et progressive. On s’assure ainsi plus tôt de partir dans la bonne direction et sur le long terme cette méthode peut faire gagner du temps (on sait précisément comment améliorer les fonctionnalités cœurs et on évite de partir dans toutes les directions sur des fonctionnalités par forcément pertinentes pour les utilisateurs).

Tous les grands produits et applications que nous utilisons de nos jours ont commencé bien différemment que ce qu’ils sont aujourd’hui ! Ils ont notamment pu se développer en s’appuyant sur la méthode de MVP.

Imaginé par Mark Zuckerberg et ses colocataires à Harvard, Facebook a commencé comme un site d'annuaire universitaire destiné spécifiquement aux étudiants de Harvard. Le site s'est ensuite étendu pour recevoir les inscriptions d'autres universités, puis s’est ouvert à des entreprises avant de devenir un phénomène mondial et d’ajouter au fil des années diverses fonctionnalités.

En 2010, Kevin Systrom ainsi qu’un autre un ingénieur de Stanford ont développé une simple application de prise et de partage de photos, avec 11 filtres simulant des techniques de développement professionnel. Après environ huit semaines de travail Instagram est né et en quelques mois l’application comptabilisait déjà un million d’utilisateur !

Pinterest a commencé sous le nom de Tote, et permettait aux utilisateurs de partager leurs coups de cœur en ligne. L'équipe a remarqué que les utilisateurs créaient des collections visuelles. Ils ont pivoté vers un modèle centré sur le partage d'images sous forme de tableaux d'inspiration, ce qui est devenu le cœur de Pinterest.

LinkedIn a lancé un MVP minimaliste qui permettait aux utilisateurs de créer des profils professionnels et de se connecter avec d'autres professionnels. L'objectif initial était de valider l'idée d'un réseau social professionnel. Avec des fonctionnalités de base, LinkedIn a prouvé qu'il existait une demande pour le réseautage professionnel en ligne. Le service a ensuite été élargi pour inclure des fonctionnalités comme les recommandations, les groupes et les offres d'emploi.

Mais alors, quels sont les inconvénients ?

Et oui, aucune méthode n’est parfaite ! Bien que le MVP soit puissant pour valider une idée de produit avec des fonctionnalités limitées, il comporte aussi des risques. Si les utilisateurs jugent que le produit est trop simpliste ou qu'il ne répond pas correctement à leurs besoins, ils peuvent rapidement s’en désintéresser. La première impression est souvent cruciale : un utilisateur déçu dès le départ sera difficile à faire revenir, même si le produit s'améliore par la suite. C'est pourquoi il est essentiel de choisir avec soin les fonctionnalités initiales à mettre en avant, celles qui offriront la plus haute valeur dès le début.

De plus, il est possible que, grâce aux retours et observations des utilisateurs, on se rende compte que la direction initiale n'était pas la bonne, obligeant l'équipe à revoir sa copie, voire à repartir de zéro. Cette non-validation par les utilisateurs peut être perçue comme un revers, mais elle présente aussi l'opportunité de pivoter rapidement et d'éviter de gaspiller du temps et des ressources sur un projet qui, au final, n'aurait jamais trouvé son marché.

Notre expérience avec l’approche par MVP

Côté Uxer, nous utilisons très fréquemment cette approche dans nos différents projets. Nous préférons proposer des fonctionnalités simples (mais pertinentes) que les utilisateurs vont pouvoir facilement prendre en main et venir les enrichir au fil du temps.

Cela permet aux clients avec lesquels nous travaillons de lancer rapidement leur produit sur le marché et de le confronter aux retours utilisateurs. Fonctionner ainsi est beaucoup plus sécuritaire que de mettre en place des fonctionnalités complexes dès le départ, surtout si l’on manque de données utilisateurs au départ du projet !

Développer des fonctionnalités poussées sur la base de nos propres suppositions est bien plus risqué, car il est vrai que nous sommes des experts du digital mais dès qu’il s’agit de médecine, de comptabilité ou de restauration par exemple, nos connaissances sont bien plus limitées, les données utilisateurs deviennent alors essentielles pour faire les bons choix !

De plus, il est beaucoup plus pénible de faire marche arrière sur quelque chose de lourd (autant en développement qu’en design, car cela peut nous obliger à repenser beaucoup d’autres éléments) que de modifier une fonctionnalité simple.

Une de nos approches pour concevoir rapidement un premier prototype d’un MVP est le design sprint. Cette méthode collaborative, répartie généralement sur 5 jours, permet de transformer une idée en un prototype concret et de le tester directement auprès d’utilisateurs réels. Chaque journée est dédiée à une étape précise : comprendre le problème, explorer des solutions, sélectionner la meilleure, créer un prototype et recueillir des retours grâce à des tests. Bien que le rythme puisse sembler contraignant, c’est justement ce qui fait sa force : il pousse l’équipe à se concentrer sur l’essentiel et à avancer rapidement.

Le développement d’un MVP permet de rapidement lancer une première version de produit, de valider la direction prise et de le faire évoluer petit à petit sur la base d’observation et des retours utilisateurs.

Il pourrait être tentant de vouloir lancer son produit avec 100% des fonctionnalités dès le départ. Mais cela comporte beaucoup plus de risque d’échec que d’y aller étape par étape. N’oubliez pas même les plus grandes applications ont commencé en étant “petites” et pourtant elles ont révolutionné notre quotidien. 😉

Pourquoi développer une version minimale alors qu’on pourrait développer toute notre idée directement ?

Pourquoi développer une version minimale au lieu de développer toute l'idée ?

4 Benefits of MVP (Minimum Viable Product) Methodology

Top 15 minimum viable product examples and stories behind them

Il est temps de faire le bilan de presque dix années d’organisation sur le terrain (déjà !). L’objectif : vous partager nos difficultés, nos réussites et nos trouvailles. Du choix de la méthode à l’organisation progressive de la production d’applications et de sites web, jusqu’à aujourd’hui !

Les premières années furent empiriques. Il s’agissait à l’époque d’une expérimentation “à ciel ouvert” et par tâtonnement successif, dans l’idée de prendre nos repères et choisir notre voie. Nous étions soumis aux quatre vents. Prêt à toutes les folies, pour signer et accompagner nos premiers projets. Prenant soir et week-end pour y parvenir, testant de multiples techniques et méthodes. Curieux de créer et à l’écoute de ceux qui nous précèdent.

C’est sur ce terreau fertile, bien qu’anarchique, que nous avons découvert le principe de l’agilité. Un grand mot qui a fait naitre notre volonté d’acquérir des fondations solides sur lesquelles structurer notre vision : transparence, collaboration, communication et adaptation. Quatre grands piliers pour s’engager à bâtir une organisation pérenne, que nous avons couplée à un cadre de travail plus pratique : S.C.R.U.M. Une méthode qui permet d’animer une équipe, au quotidien, autour d’un but commun : celui de créer des produits de la plus grande valeur possible.

Nous avions en l’espace de quelques mois de quoi faire pour continuer notre expérience grandeur nature et organiser notre travail autour de ce grand principe et de cette méthode. Nous avons aussi rencontré notre première difficulté : organiser notre travail à partir d’un principe et d’une méthode si spécifique - qui plus est face à des interlocuteurs massivement peu formés à ce type de pratique - peut vite devenir un véritable casse-tête !

Nous étions constamment tiraillés entre notre volonté de bien faire en appliquant une méthode à la lettre et la réalité du terrain...

En effet, dans un projet, nos interlocuteurs (clients ou utilisateurs) détiennent une quantité de savoir qu’il nous faut recueillir et organiser pour garantir le respect des besoins exprimés. Nous devons aussi communiquer et faire comprendre les enjeux et les contraintes du projet à tous, et suivre l’évolution dans le temps. Et enfin, nous devons nous adapter à chaque instant pour remplir les objectifs fixés. Toutefois, il est très vite apparu que cette démarche de communication, de sensibilisation et de formation, sur la base de la méthode S.C.R.U.M, garante de notre capacité à produire, n’était pas facilement déployable pour la majorité des projets que nous voulions accompagner.

Pourquoi ? L’agilité suppose une souplesse et un engagement qui est loin d’être un acquis, encore moins dans l’hexagone - bien que cela puisse évoluer positivement avec le temps. La pratique soulève de nombreuses incertitudes et peut susciter des craintes ; qui sont autant de freins, légitimes ou non, à l’adoption.

Nous avons très vite été confrontés au besoin de pallier ces difficultés, notamment par la rédaction de conditions contractuelles interminables, détaillant chaque principe de la méthode à adopter, et autant de clauses spécifiques. Afin de nous adapter à la réalité d’un marché qui n’était pas prêt à croire les yeux fermés en la vertu de notre approche.

De fil en aiguille, nous risquions également de tomber dans l’un des nombreux pièges de cette belle intention qu’est l’agilité. Comme de répercuter les manquements sur une équipe qui produit, en les contraignant davantage dans leurs travaux dans le seul but d’apporter des garanties supplémentaires à nos clients. Ou bien de transformer la promesse de transparence et d’autonomie en une surveillance continue de l’équipe et des individus ; une ingérence contre-productive qui contrevient à l’idée première de confiance envers son équipe de travail.

Bien qu’aucune méthode ne soit directement responsable des biais provoqués par une mauvaise mise en œuvre de celle-ci, les pièges évoqués sont des travers classiques et sont le fruit des incertitudes de l’humain, qui cherche à contrôler toujours plus une situation à mesure que la place des inconnus grandit.

Face à ce constat cinglant, disons cette impasse, il nous fallait déconstruire la méthode (n’en déplaise aux puristes) pour recréer à partir de nos propres contraintes une méthode plus proche de notre réalité. Un hybride plus adapté à la taille et aux moyens de notre structure tout en conservant les valeurs de l’agilité. Voyons ce qu’il en est !

Je propose de développer ici les évolutions clés de la méthode S.C.R.U.M, celles qui ont transformé la manière de l’aborder tout en gardant (d’après nous) les grands principes de l’agilité. Ce sont nos choix, ils sont parfaitement discutables et sont d’ailleurs une source de débats internes constant. De plus, ils continuent d’évoluer avec le terrain et l’expérience, mais de grandes lignes de forces s’en dégagent, les voici !

Une production organisée autour d’un seul kanban, par périodes successives et continues, multi-projet et multi-métiers. Voici la base de notre organisation et la vision fondamentale dont découlent les autres aspects de notre méthode.

Nous aurions pu opter pour un kanban par projet et/ou par métier, mais la taille de notre équipe (8 personnes en moyenne) et l’impossibilité d’organiser autant de rituels que de projets, nous plaçaient devant l’évidence même. Ainsi, un sprint, c’est-à-dire une période de production, devait pouvoir accueillir plusieurs projets, et l’ensemble de nos métiers, sur une période définie et répétable à l’infini (par itération continue). Nous avons donc opté pour des périodes de 15 jours, car nous y trouvons un excellent compromis entre rapidité d’exécution des travaux engagés et durée suffisante pour s’organiser en équipe et travailler sur des incréments de toutes tailles.

Finalement, après plusieurs années, ce rythme est toujours celui que nous pratiquons.

Aujourd’hui, nous pourrions même envisager de doubler notre capacité productive en organisant plusieurs kanbans en parallèle si l’équipe venait à s’étoffer au-delà d’une certaine taille tout en conservant la souplesse d’une équipe agile. Il nous arrive parfois également de créer des kanbans supplémentaires, afin de répondre à un besoin spécifique et éphémère. Pour appliquer, par exemple, les conditions d’une période de garantie.

Cette “scalabilité” qui donne la souplesse de notre organisation suppose toutefois de disposer d’une direction solide pour piloter une vue d’ensemble. Nous avons passé beaucoup d’années à suivre les indicateurs clés de l’agilité sans toutefois y trouver une véritable source d’inspiration. Je parle notamment de la vélocité qui est un indicateur très fiable de la capacité productive d’une équipe, mais qui trouve rapidement ses limites. Quand l’équipe est rodée - après quelques mois de production - cet indicateur perd de son intérêt, car les personnes développent rapidement une forme d’intuition, qui leur permet de définir la charge et de suivre le rythme de travail en autonomie. Sauf à tordre le calcul de la vélocité pour en faire un objectif de performance, ce qui d’après nous est un écueil à éviter absolument !

Ainsi, nous pratiquons l’estimation de nos tâches - à l’aide de la suite de Fibonacci - et nous suivons toujours cet indicateur afin de garantir une vision de la charge et d’orienter nos décisions. Nous utilisons toutefois assez peu l’indicateur de vélocité pour les raisons évoquées précédemment. Nous doublons cependant notre estimation avec le suivi des temps passés (Time Tracking) par l’équipe afin d’enrichir notre base de connaissance dans le but de compléter nos historiques, d’affiner nos estimations futures et de répondre aux enjeux de transparence auprès de nos clients.

De manière logique : nous itérons, restituons et découpons le fruit de nos travaux, de nos recherches, et des réflexions issues de nos échanges, dans un backlog fonctionnel. Une liste de fonctionnalités que nous hiérarchisons à l’aide d’épiques, de versions et de stories. Ainsi, nous racontons l’histoire de ce qui doit devenir une application web pleinement utilisable à l’aide d’une pratique plutôt scolaire de la méthode. Qui a fait ses preuves !

Nous n’hésitons pas cependant à réorganiser nos tâches, à les renommer et réécrire au fur et à mesure de la création du produit : que ce soit par projet, par métier, et par lot de fonctionnalités front-end et back-end. Cela intègre bien un ensemble de fonctionnalités (stories), mais elles n’apparaissent plus nécessairement en cohérence avec le découpage de la méthode initiale, hum… 🤔

Nous laissons ainsi plus de place à la capacité créative et organisationnelle de l’humain qui est en charge de l’incrément en lui laissant une plus grande souplesse de structure et de réflexion ; capacité qui diffère en fonction des personnes et de la composition d’une équipe. Nous faisons ainsi un pas de plus dans l’autonomie d’une équipe de travail.

Rassurez-vous (pour ceux qui s’inquiètent 😅)! Cette méthode est rodée et nous gardons le fil, car le backlog (c’est-à-dire la liste des fonctionnalités qui peut se compléter d’un ensemble d’autres supports de travail) reste la base documentaire et fonctionnelle de référence et accompagne le projet et les discussions jusqu’à sa recette, sa livraison, et même après.

Nous n’attendons pas nécessairement la fin d’une période de production pour livrer le fruit de notre travail (comme il est d’usage dans la méthode). Nous avons fait le choix de livrer et de présenter le résultat des travaux indifféremment de la période dans laquelle nous sommes (début, milieu ou fin de sprint). C’est un choix complexe, mais nécessaire dans notre cas, car nous traitons de multiples projets et avons de multiples clients. Nous ne pourrions tous les livrer simultanément.

De plus, une solution web peut être amenée à évoluer très rapidement, par petites itérations successives, sans forcément qu’il soit indispensable de se soucier immédiatement de la finition et du rendu graphique de celle-ci. Dans notre cas, c’est différent, car nos clients et nous-mêmes attachons autant d’importance à la valeur du rendu final qu’à la valeur fonctionnelle. La valeur fonctionnelle n’étant pas nécessairement perçue aussi aisément et aussi rapidement que le rendu visuel. D’où l’importance de soigner le résultat de nos incréments livrés.

Ainsi, nous adaptons nos périodes de livraison en fonction d’un découpage par lot qui tient compte de la valeur globale du produit, et non uniquement de son aspect fonctionnel ou d’une liste de fonctionnalités prédécoupées, additionnées et priorisées.

Cela pourrait semblait contrevenir aux attentes de la méthode, qui du fait de sa technicité apparente, semble attacher plus d’importance à la valeur fonctionnelle d’un produit, sans donner autant d’importance par exemple à l’esthétisme ou à l’ergonomie, et encore moins à l’impact sur son environnement.

Mais, dans notre expérience, la recherche d’incrément rapide, évolutif et parfaitement fonctionnel ET un design soigné couplé à une ergonomie bien étudiée ET une réflexion autour des impacts environnementaux, sont des objectifs qui ne s’opposent pas nécessairement - pour peu que la chaîne de production intègre et garantisse lesdites valeurs dans toutes ses étapes de travail.

Cela demande toutefois une plus grande sensibilité et une coordination des métiers, ce qui rejoint notre vision d’une production multi-métiers et ouvre à une communication plus fluide de l’équipe avec nos clients.

Enfin, cet enrichissement croisé vient compléter les attendus de ceux qui héritent du résultat des travaux précédent. Notamment par l’amélioration des livrables proposés. Et une plus grande richesse de savoir dans les moments de transmission entre les différents métiers. Cela reste toutefois un véritable champ d’exploration sur lequel nous apprenons, encore et chaque jour, pour nous améliorer !

Une chose ne change pas chez Uxer : les rituels ! La valeur des cérémonies proposées par la méthodologie S.C.R.U.M est indéniable. Qu’il s’agisse du Daily chaque jour, de la Planification, de la Revue et la Rétrospective à chaque sprint, il apparait difficile de procéder autrement tant chaque moment apporte de véritables gains, est convivial et assure un suivi de qualité. C’est l’esprit même de la méthode et son essence indéfectible.

Ceci étant dit. Nous étions face à une nouvelle difficulté lors du rituel de la planification, car comme déjà exposé, nous traitons de multiples projets, mais aussi des langages de code qui diffèrent et des expertises qui ne sont pas toujours partagées uniformément au sein de l’équipe - et cela même si l’équipe se veut pluridisciplinaire.

Il y a en effet des limites qui sont difficiles à dépasser surtout quand le savoir acquis provient d’une très longue expérience. Il apparaissait alors irréaliste de lister nos projets, missions et tâches ou de planifier des lots de travail, puis de demander à l’équipe de prendre chaque tâche dans l’ordre et indistinctement.

La solution trouvée ? La voici : assigner la plupart de nos tâches dès la planification.

Nous sortons là encore de l’usage classique qui voudrait que l’assignation soit progressive et prise dans l’ordre de la priorisation initiale. C’est toutefois une décision réfléchie, prise en autonomie par l’équipe pour chacune de nos tâches, et cela même si des préconisations peuvent être faites par le responsable du projet (Le Product Owner). De plus, l’équipe conserve la possibilité à tout moment de modifier sa décision.

Selon nous, et après plusieurs années d’expérimentation, cette hybridation de la méthode permet une plus grande finesse d’organisation, une meilleure répartition de la charge d’un sprint, surtout au départ d’une période, sans pour autant s’opposer à la priorisation globale et à la souplesse d’une assignation plus tardive.

Nous pratiquons également l’échange d’une tâche par une autre de même valeur ou de valeur similaire pour peu que l’équipe soit en accord avec cette modification du périmètre à produire.

Aujourd’hui encore, nous tentons, par l’expérience concrète, d’allier les grands principes du manifeste agile en rendant vivante la méthode. Les évolutions des réalités humaines, pratiques et technologiques, du secteur de la création et du développement d’applications et de sites web, nous emmènent sur des chemins nouveaux, qui, à mon sens, n’annulent en rien l’ancien monde. Elles nous invitent au contraire à approfondir les valeurs intrinsèques de nos méthodes et de la vision de notre travail, au quotidien et dans la durée. Et leurs conditions d’application dans les entreprises, pour les renouveler et leur donner toujours plus de sens.

Retour d’expérience sur 10 années d’agilité en agence, ce qu’on a gardé, ce qu’on a modifié et quelques unes des leçons que l’on en a tiré !

“Plus que 3 articles en stock ! 😱”. Je suis quasiment certaine que vous avez déjà rencontré ce type de message vous forçant à passer rapidement à l’action lors de vos achats en ligne. Il s’agit d’un dark pattern.

Les dark patterns (ou deceptive design) sont des interfaces volontairement truquées qui ont pour objectif d’induire en erreur ou de manipuler les utilisateurs, dans le but de leur faire accomplir des actions non voulues ou de masquer des actions non souhaitées par l’entreprise (suppression d’un compte, résiliation d’abonnement).

Ces interfaces malhonnêtes sont bien plus répandues qu’on ne le pense. C’est pourquoi il est fondamental de sensibiliser à ce sujet afin de permettre aux utilisateurs de les identifier et d’éviter les pièges.

Pour les designers, avoir connaissance de ces pratiques permet de créer des interfaces “saines”, car bien que rentables à court terme, les dark patterns nuisent à l’expérience utilisateur.

D’où viennent les dark patterns et pourquoi sont-ils utilisés ?

C’est Harry Brignull, un spécialiste de l'UX design et de la psychologie cognitive, qui en 2010, a introduit le terme dark pattern. Pour lui, “un dark pattern est une interface utilisateur soigneusement conçue pour tromper les utilisateurs”.

Dans notre quotidien, certaines stratégies marketing sont bien ancrées comme les prix à X,99€, les offres type “pack économique” (qui ne sont pas toujours des bons plans quand on fait le calcul), etc. Ces stratégies se basent sur ce qu’on appelle les biais cognitifs.

Les biais cognitifs sont des distorsions dans notre façon de penser qui nous amènent à prendre des décisions ou à porter des jugements de manière irrationnelle, souvent sans en être conscients.

Prenons par exemple la première phrase de cet article :

ou dans le même style “Offre limitée, seulement 2 heures restantes !”

Ce type de phrase dans une interface va jouer sur le biais d'urgence qui pousse les gens à agir rapidement, souvent sans réfléchir, les amenant à acheter quelque chose dont ils n'ont pas vraiment besoin.

Il existe en réalité une multitude de biais cognitifs ! Je ne m’attarde pas plus sur ce sujet aujourd’hui, mais ça pourra faire l’objet de futurs articles 👀 L’important est que vous compreniez que les darks patterns s’appuient sur nos biais cognitifs, mais aussi sur des astuces de design bien rodées que nous allons voir par la suite.

Parenthèse fermées pour les biais cognitifs, revenons en aux dark patterns ! Ils sont comme les stratégies marketing malhonnêtes du web. Ils ont généralement pour objectif de :

Augmenter les conversions (vendre en d’autres termes)

De manière plus générale, retenez que les darks patterns sont utilisés à des fins commerciales (et oui vos données personnelles valent de l’or elles aussi).

Harry Brignull a également réalisé un site qui regroupe et expose des exemples de ces pratiques pour sensibiliser le public.

En voici une sélection non exhaustive avec des exemples pour les repérer et éviter de tomber dans les pièges :

Les formulaires ou questions sont formulés de manière trompeuse, incitant les utilisateurs à choisir une option qu'ils n'avaient pas l'intention de sélectionner. Les négations (et parfois doubles négations) sont souvent utilisées dans ces cas de figure car elles sont plus difficiles à comprendre que des phrases affirmatives.

Exemple :  “Je préfère ne pas bénéficier des offres exclusives et des réductions pour membres.” Dans cet exemple, l'option semble encourager l'utilisateur à ne pas cocher la case, car personne ne voudrait "perdre" des offres exclusives. Cependant, en réalité, si l'utilisateur ne coche pas la case, il s'inscrit automatiquement aux offres et newsletters, alors qu'il pourrait ne pas en vouloir.

Les utilisateurs bénéficient d'une offre d'essai gratuit, mais ils sont ensuite facturés automatiquement une fois la période d'essai terminée, sans avertissement ou avec un processus d'annulation compliqué.

Une action semble mener à un résultat attendu, mais elle conduit en fait à quelque chose d'inattendu.

Exemple : Un utilisateur clique sur un bouton pour obtenir des informations, mais en réalité il s’inscrit à un service.

L'attention de l'utilisateur est délibérément détournée pour l'amener à faire quelque chose qu'il ne souhaite pas.

Exemple : Une option d'acceptation est visuellement plus mise en avant que l'option de refus, ce qui pousse l'utilisateur à accepter par inadvertance.

Il est facile de s'inscrire à un service ou un abonnement, mais très difficile de s'en désinscrire ou de fermer un compte.

Exemple : L'utilisateur doit passer par plusieurs étapes compliquées ou contacter le service client pour annuler un service.

L'utilisateur est poussé à partager plus d'informations personnelles qu'il ne le souhaite, souvent de manière subtile ou trompeuse.

Exemple : Des paramètres de confidentialité sont automatiquement définis pour rendre les informations publiques sans que l'utilisateur en soit conscient.

Une tentative de manipulation par la culpabilité, où l'utilisateur est amené à se sentir mal s'il refuse une offre ou choisit de ne pas agir.

Exemple : Le bouton pour refuser une offre est libellé de manière à faire honte, comme "Non, je n'aime pas économiser de l'argent."

Un article supplémentaire est ajouté automatiquement dans le panier sans le consentement explicite de l'utilisateur.

Exemple : Lors d'un achat, un produit complémentaire (comme une assurance ou un accessoire) est ajouté par défaut dans le panier.

Des publicités sont déguisées sous forme de contenu ou de fonctionnalités légitimes, trompant les utilisateurs en leur faisant croire qu'il s'agit d'un élément de l'interface qu'ils doivent interagir.

Exemple : Une annonce ressemble à un bouton de navigation ou une fonction d'un site.

L'utilisation de dark patterns dans une interface présente un risque majeur : celui de perdre la confiance des utilisateurs. En évitant ces pratiques trompeuses, vous facilitez leur parcours tout en renforçant leur sentiment de sécurité.

La confiance est un élément clé de la fidélisation : un utilisateur qui sait qu'il ne rencontrera pas de piège reviendra plus volontiers et naviguera avec plaisir sur un site. Pour les grandes marques, l'utilisation de dark patterns peut avoir des conséquences encore plus graves, en ternissant durablement leur image.

Ces pratiques abusives touchent souvent les utilisateurs les moins familiers avec le numérique, ce qui rend crucial de sensibiliser largement à ce problème, d’autant plus que les stratégies trompeuses se perfectionnent.

Enfin, pour les designers, n’oubliez pas que répondre à des objectifs commerciaux ne doit jamais se faire au détriment de l’expérience utilisateur. Une conception éthique et respectueuse est la clé pour bâtir des relations durables et authentiques avec vos utilisateurs. 😌

Conspirations, complots 😈 ?! Non, juste des techniques UX un peu malhonnêtes…

Les pièges des dark patterns sur les sites internet

Dark patterns, des interfaces qui cherchent à vous piéger

Pièges sur les sites de commerce en ligne : attention aux dark patterns !

Aujourd’hui, on parle de cohérence dans le design, du rythme d’affichage des informations et des fonctionnalités, et de la hiérarchie des contenus.

Dans le premier article, je parlais déjà de l’importance de la cohérence dans une interface. Je parlais notamment de la cohérence de la structure et des couleurs. Mais j’ai envie d’en remettre une couche, car c’est selon moi un des éléments les plus importants.

Que ce soit dans un site web, une application mobile ou une application métier complexe, l’utilisateur doit ressentir une continuité dans son expérience et sa navigation. Que ce soit au travers de la structure des vues, mais également des éléments qui les composent.

D’où l’intérêt d’utiliser un design system ou au moins un kit UI, dont je parlais plus en profondeur dans mon dernier article. En effet, utiliser une bibliothèque de composants d’interface permet d’assurer une cohérence de logique et de fonctionnement pour l’utilisateur. Inutile de réinventer la roue pour chaque bouton, chaque élément de menu ou chaque formulaire. Au contraire, la répétition permet de créer des habitudes pour vos utilisateurs, qui utiliseront votre application efficacement et plus rapidement.

Au contraire, lorsque vos utilisateurs tomberont sur des éléments d’interfaces différents de leurs habitudes : un bouton plus gros ou une forme différente par exemple, cela pourrait générer de la confusion.

Affichez les informations progressivement

Afin de guider au mieux un utilisateur lors de l’accomplissement d’une tâche, il est important de contrôler la quantité d’informations affichée sur une même vue. En effet, l’affichage de trop d’informations peut créer une surcharge cognitive pouvant décourager un utilisateur.

La solution est donc de découper une seule grosse étape - qui seraient trop chargée en informations et fonctionnalités - en plusieurs étapes plus petites et surtout plus digestes. Séquencer les informations/fonctionnalités est crucial pour s’assurer de la bonne compréhension de chaque élément par l’utilisateur et augmenter les chances qu’il complète le parcours.

Attention cependant, il est important de guider son utilisateur en lui indiquant où il se trouve dans un parcours, combien d’étapes il reste et idéalement lui apporter une solution pour quitter en cours de route sans perdre sa progression.

Il est également recommandé d’exposer son utilisateur aux fonctionnalités de manière progressive en terme de complexité. Commencer avec des fonctionnalités simples au début de l’expérience permet d’éviter de faire fuir son utilisateur afin qu’il apprivoise l’application à son rythme. Puis progressivement, on peut ajouter des fonctionnalités de plus en plus poussées et complexes.

C’est quelque chose que l’on retrouve par exemple dans l’onboarding des applications mobiles ou encore dans beaucoup de jeux mobiles : au premier lancement, les fonctionnalités sont limitées et se débloquent au fur et à mesure des parties. Cela permet d’assurer une courbe d’apprentissage douce.

La hiérarchie visuelle est ce qui détermine l’ordre dans lequel vos utilisateurs vont voir les informations sur une page. Une bonne hiérarchie doit donc guider les utilisateurs vers du contenu ou des actions importantes.

Toutes les informations n’ont pas le même niveau d’importance. L’idée est donc de structurer les pages de son site ou application pour faire ressortir certains éléments plus que d’autres. Une bonne hiérarchie visuelle permet à l’utilisateur de scanner la page plus efficacement et de se concentrer sur les éléments importants. Pour y arriver, on peut utiliser des propriétés comme la taille, les espacements, la position, la couleur et bien d’autres.

Un test simple et rapide pour vérifier si des informations sont correctement hiérarchisées consiste à plisser les yeux, à flouter son design ou à l’observer en s’éloignant de l’écran. L’idée étant de toujours discerner les éléments les plus importants en premier. Si tout ne ressemble qu’à une seule masse floue, sans reliefs, c’est qu’il y a surement des amélioration à faire sur la hiérarchie visuelle.

Voilà qui conclu cette seconde partie de règles du design d’interface. Dans le prochain article, j’aimerai aborder le sujet des principes de Gestalt et comment ils peuvent nous aider à concevoir et designer de meilleures interfaces.

Cohérence dans le design, rythme d’affichage des informations et des fonctionnalités et hiérarchie des contenus

C’est reparti pour la suite de notre article sur les règles importantes à connaître et à appliquer lorsque l’on travaille sur du design d’interface. Et il était temps puisque cela fait un peu plus de 2 ans que la première partie a été publiée.

D’autres règles du design d’interface

16 little UI design tips that make a big impact

5 essential UI design principles—and how to use them

Design, code & vied’une agence bordelaise