Quand vous baignez dans l’open-source, vous finissez par vous imprégner d’une certaine culture. Pas seulement celle de collaborer et de travailler en toute transparence à la vue de tous, mais aussi celle de savoir collaborer efficacement en toute autonomie dans l’optique de livrer le meilleur produit. De cette émulation naît la qualité et l’innovation. On retrouve ces valeurs et cette culture dans les start-ups qui ont développé leurs produits à partir de l’open-source et qui en sont par la suite devenus des acteurs majeurs comme c’est le cas de Google (Angular), de Facebook (React) ou de GitHub (Jekyll). Quels sont donc les secrets pour développer un bon produit ? C’est ce que partage avec nous @benbalter, contributeur open-source invétéré et actuellement en charge de GitHub Pages, le service d’hébergement gratuit de sites web statiques de GitHub.

J’ai passé une partie de mon temps libre pendant ces trois dernières années à jouer avec le code de GitHub Pages et depuis janvier dernier j’ai accepté de gérer GitHub Pages à temps complet. Apparemment je faisais depuis un moment déjà ce que certains appellent de la gestion de produit — même si je n’appelais pas cela ainsi à l’époque — et lorsque j’ai commencé à exercer mon premier rôle formel de chef de produit, j’ai réalisé qu’il y avait tout un tas de leçons que j’avais apprises au cours des dix dernières années que j’avais passé à créer des logiciels et qui m’ont fondamentalement enseigné ce que je pense être la meilleure façon de développer des produits, qu’ils soient propriétaires, publics ou open-source.

1. Masquez la complexité aux utilisateurs

L’internet est un environnement compliqué et la plupart des sites web ne font rien pour y remédier. Avant toute chose, les produits devraient aspirer à se préoccuper de l’utilisateur. Votre boulot en tant que créateur c’est de concevoir des choses simples au sein d’un système autrement plus complexe, de s’appuyer sur la technologie pour réduire la charge cognitive nécessaire pour accomplir les tâches quelconques que votre utilisateur essaie de mener à bien et pour laquelle votre produit se met en travers du chemin. À chaque fois que vous masquez un contenu via un effet toggle, que vous ajoutez un menu déroulant ou une zone de saisie, vous imposez de la complexité aux gens et vous leur demandez une nouvelle décision, qu’ils n’auraient pas à prendre s’ils n’utilisaient pas votre produit. Un logiciel devrait être difficile à concevoir et facile à utiliser. Pas l’inverse.

Exemple : Quand la compilation d’un site GitHub Pages échoue, nous avons accès à toutes sortes d’informations pour faire un diagnostic : les permissions de l’utilisateur qui a fait la demande, la version de chaque dépendance logicielle que nous utilisons, quand est-ce que le processus de compilation s’est précisément arrêté, les journaux de déboggage de l’erreur, la liste est longue. Plutôt que d’afficher la sortie brute de la compilation à l’utilisateur et lui demander de comprendre ce qui s’est passé, nous détectons la cause sous-jacente, si nous le pouvons, et lui affichons un message d’erreur court et détaillé avec des liens vers la documentation correspondante.

2. Ajoutez des fonctionnalités que 80% des gens utiliseront

C’est facile (et amusant) d’optimiser pour les utilisateurs avancés et de résoudre des cas limites. Le vrai défi, pour tout produit, réside dans le fait d’arriver véritablement à proposer une expérience facile d’accès pour 80% des gens. Pour un geek, c’est toujours plus marrant de développer la dernière fonctionnalité top-moumoutte qui va permettre à l’application d’interagir avec le dernier outil en vogue sur Hacker News. En tant que chargé de la maintenance du projet, c’est toujours plus gratifiant de mettre du code en ligne que de fermer un ticket taggué en wontfix. Dans le même temps les utilisateurs experts les plus investis dans votre produit sont ceux qui se feront le plus entendre. Ajouter un paramètre c’est facile. Planquer ce paramètre dans les profondeurs d’un onglet « Paramètres avancés » est encore plus simple. Ne cédez pas à la tentation de vouloir faire ressembler toujours un peu plus votre produit à une cabine de pilotage.

Exemple : GitHub supportait à l’origine cinq interpréteurs de Markdown, chacun avec ses propres singularités. Les donnés ont montré que 97% des utilisateurs utilisaient l’interpréteur par défaut. Supprimer les quatre autres moteurs de rendu nous a permis de faciliter l’expérience utilisateur et de développer des fonctionnalités plus impactantes, plutôt que de maintenir une compatibilité ascendante.

3. Buvez votre propre champagne

Il existe des exemples de bons produits qui n’ont pas été utilisés quotidiennement par les équipes qui les ont développés. Et d’abord, pourquoi voudriez-vous soumettre vos utilisateurs à une expérience que vous n’estimez pas suffisante pour satisfaire vos propres besoins (ou que vous ne connaissez pas assez bien car vous n’avez pas rencontré le problème vous-mêmes) ? Mangeriez-vous dans un restaurant dans lequel le chef ne veut pas manger ou dont il n’a pas goûté la nourriture ? Quand vous utilisez un produit tous les jours, chaque défaut, chaque fonctionnalité manquante, chaque recoin bancal de votre application devient une forme passive d’auto-flagellation, du moins jusqu’à ce que vous ne les corrigiez. Sans parler du fait que cela vous permet de tester une fonctionnalité à l’état brut, avant de la soumettre aux utilisateurs. Goûtez à votre propre tambouille, comme on dit souvent ou « buvez votre propre champagne » comme je préfère dire, cela vous procure un sentiment d’empathie inégalable envers les utilisateurs, un niveau de compréhension que vous ne fournira jamais aucun groupe de discussion ou d’étude de marché.

Exemple : Chez GitHub, non seulement beaucoup d’employés de GitHub utilisent GitHub Pages pour héberger leur propre site ou leur blog, mais nous encourageons les autres équipes à utiliser GitHub Pages aussi souvent qu’elles le peuvent. Les utilisateurs bénéficient indubitablement des meilleurs tests sur divers cas de figures. Nous avons ajouté le plugin Jekyll SEO Tag depuis un petit moment déjà. Le plugin insère automatiquement des métadonnées pour que les moteurs de recherches puissent mieux indexer votre site. Quand nous l’avons autorisé pour GitHub Pages, nous ne l’avons pas annoncé. Au lieu de ça, nous l’avons d’abord utilisé en interne pour des sites GitHub comme desktop.github.com, pour voir s’il était performant, puis nous l’avons ajouté à la gem1 GitHub Pages pour que les utilisateurs téméraires puissent expérimenter avec, avant de finalement communiquer publiquement dessus.

4. Optimisez pour le cas d’utilisation idéal, pas le cas le plus courant

Si un utilisateur peut faire quelque chose avec votre produit, il le fera. Cela crée beaucoup d’usages inattendus et de demandes de nouvelles fonctionnalités auxquelles vous n’aviez pas pensé. Indépendamment de la façon dont est vraiment utilisé, guidez les utilisateurs dans la bonne direction. Encouragez les à faire ce que vous voulez qu’ils fassent. Cela se traduira par proposer des fonctionnalités qui prennent en charge votre cas idéal, pas le plus courant, celui utilisé par la majorité de vos utilisateurs, ou ceux qui se manifestent le plus.

Exemple : GitHub Pages est utilisé pour différentes choses, pour des applications de statut automatisé mais aussi des boulangeries locales. C’est prévu pour être utilisé par des personnes, des organisations et des projets. Au lieu d’investir dans des scénarios d’usage non liés à GitHub, nous avons simplifié la publication de métadonnées sur votre activité sur GitHub, comme la liste des projets open-source les plus populaires de vos organisations, même si ce scénario d’usage n’était pas populaire lors de l’introduction de la fonctionnalité.

5. Laissez les utilisateurs faire les changements

Une fois que vous avez ajouté une fonctionnalité, vous avez passé un contrat implicite à vie avec l’utilisateur, un contrat qui vous demande de prendre en charge cette fonctionnalité pour toujours. Parfois les choses doivent changer. Vous voulez revoir le design. Ce n’est plus la direction dans laquelle vous souhaitez vous engager. C’est trop dur à prendre en charge. Seule une infime partie de vos utilisateurs l’utilisent. Quelqu’en soit la raison, ne cédez pas à la tentation de couper l’herbe sous le pied de vos utilisateurs. Expliquez pourquoi vous faites ce changement, avertissez-les au préalable, indiquez leur comment se mettre à jour et laissez-les faire les corrections, plutôt que de les faire à leur place (et par la même de risquer une violation du contrat du produit)

Exemple : Dans le cas de GitHub Pages, nous voyons souvent se produire ce genre de situation lors mises à jour de dépendances majeures, surtout quand elles impliquent des changements inévitablement non rétro-compatibles. Quand un utilisateur fait un changement qui casse son site, c’est frustrant, mais il peut toujours le corriger à son rythme (et comprendre par là même l’origine du problème). Quand des changements généralisés cassent le même site en douce, c’est juste frustrant.

6. Fournissez toujours un exemple

Je ne me rappelle plus la dernière fois que j’ai lu un guide utilisateur, qu’il concerne un objet, un logiciel ou autre chose. Il serait vain de croire que votre utilisateur a lu votre documentation, surtout si elle n’a pas évoluée depuis qu’il a commencé à utiliser votre produit il y a six mois, un an ou cinq ans déjà. Préférez plutôt fournir un bouton bien visible pour l’inciter à aller consulter la documentation, à chaque fois que vous communiquez avec vos utilisateurs, que ce soit via une aide pour utiliser une case à cocher dans les paramètres, un message d’erreur ou un article de blog annonçant une nouvelle fonctionnalité. Quand vous ne le faites pas, vous conduisez vos utilisateurs dans une impasse, qui aura pour effet de générer de la frustration et l’ouverture en dernier recours d’un nouveau ticket de support ou d’une demande d’aide. Pour chaque interaction, indiquez toujours la prochaine étape à l’utilisateur sous la forme d’une URL.

Exemple : Chaque fois que vous recevez une notification d’échec de compilation ou un avertissement de la part de GitHub, nous avons des tests d’intégration continue en place pour nous assurer non seulement que le lien pointe vers la documentation adéquate (et donc vers les corrections à appliquer) mais aussi que ce lien est toujours valide. En plus de cela, la plupart des interfaces de GitHub Pages ont des liens implicites ou explicites vers la documentation adéquate quand nous repérons une erreur.

7. Soyez aussi léger que possible

S’il y a une solution plus simple et que vous ne l’utilisez pas, vous êtes en train de faire des choses trop compliquées. Jetez un œil aux outils existants (pensez open-source), services (pensez APIs RESTful) et aux pratiques (pensez normes communes) avant de créer la votre. Des applications plus simples, moins complexes, avec moins de parties changeantes, sont plus faciles à faire évoluer, plus facile à maintenir et ont potentiellement moins de points de défaillance. Sans parler du fait que commencer avec une solution légère vous permet de vous reposer sur l’expérience des autres et de valider individuellement tout nouvelle hypothèse très tôt. Vous évitez ainsi un trop gros investissement technique où il sera très difficile de corriger le tir ou dont le coût sera prohibitif. Dit autrement, ne réinventez pas des parties de la roue, sauf si vous n’avez pas d’autre choix. Concentrez-vous sur l’ajout de valeur, qui est a priori censé être votre cœur de métier.

Exemple : Pendant ses six premières années d’existence, GitHub Pages était un simple script shell d’une centaine de lignes et les sites générés étaient servis par deux serveurs Nginx standards. Ça a marché pour près d’un million de sites, mais au fur et à mesure que les choses ont évolué, nous avons fini par devoir ajouter plus de complexité, mais cette complexité n’était pas nécessaire au départ et était minimale une fois qu’elle l’était devenue.

8. Itérez, Itérez, Itérez

Si vous n’avez pas honte de la première version de votre produit, c’est que vous l’avez lancé trop tard. Pas besoin que ce soit parfait ou complet. Ça ne devrait pas l’être pour tout dire. Publiez tôt, publiez souvent. Pour reprendre une phrase célèbre chez les techos, ne laissez pas le mieux être l’ennemi du bien (ou de l’apprentissage par la validation). Livrez ce que vous pouvez, commencez petit et montez en puissance jusqu’à la destination de votre choix. Si vous pouvez livrer une petite itération faites-le. Si vous pouvez livrer à un ensemble plus restreint de parties prenantes en interne, encore mieux. Observez comment les clients perçoivent les choses et adaptez-vous en conséquence. Soyez transparents, répondez aux attentes. Laissez évoluer votre vision. Quand c’est possible, vous devriez sortir publiquement une version 0.1, pas 1.0.

Exemple : Le support d’HTTPS pour GitHub Pages est une des fonctionnalités les plus demandées. Supporter HTTPS pour plus d’un million de sites n’est pas une mission d’ingénierie insignifiante, cela demande des changements à plusieurs niveaux dans l’infrastructure technique. Bien que nous prévoyons éventuellement de supporter HTTPS pour les noms de domaines personnalisés, nous avons livré les changements de manière progressive sur le réseau, le répartiteur de charge, l’application et les différents routeurs pour supporter HTTPS pour les sites en github.io (en gardant le support de domaine personnalisé en tête) puis validé que ces changements fonctionnaient comme prévus, en espérant nous baser sur ces livraisons pour avancer.

9. Poussez la logique jusqu’au bout

Quand on travaille dans le domaine de la technologie, les processus lourds et centralisés reposant sur des personnes sont rarement adaptés. Lorsque vous concevez des systèmes, éviter les points individuels de défaillance, que ce soit en ligne ou hors-ligne, qui servent le plus souvent d’inhibiteurs. Au contraire automatisez (ou éliminez) tout ce que vous pouvez. En d’autres termes, ne forcez pas un être humain à faire ce qu’un ordinateur peur faire à sa place, ou comme j’aime à le répéter, « éliminez tous les humains ». Quand l’automatisation n’est pas possible, décentralisez l’autorité et responsabilisez les communautés pour qu’elles puissent devenir autonomes en déléguant les décisions au maximum. Ayez confiance dans les gens. Plutôt que de créer une équipe entière à la gestion d’un process ou d’une tâche, encouragez les écosystèmes techniques, légaux et culturels. Et plus que tout, avec les ordinateurs et les gens, n’ajoutez pas de verrous opérationnels.

Exemple : Si vous voulez configure un domaine personnalisé avec GitHub Pages, vous devez configurer les paramètres DNS de votre domaine, une tâche potentiellement complexe et déconcertante. Pendant les sept premières années d’existence de GitHub Pages, si votre domaine était mal configuré, vous deviez envoyer un mail au support de GitHub, qui à son tour, devait souvent demander de l’aide à l’équipe de GitHub Pages. Nous avons préféré automatiser les diagnostics que nous faisions habituellement, en créant la Gem GitHub Pages Health Check, dévoilant ces vérifications directement aux utilisateurs (sans qu’ils aient à contacter le support) et pour l’équipe de support sous la forme de ChatOps et de ce que vous appelons des stafftools (sans avoir à contacter l’équipe de GitHub Pages). Cela permet une (auto-)résolution plus rapide des mauvaises configurations de DNS et aujourd’hui cet outil est open-source, ce qui signifie que les utilisateurs peuvent améliorer la détection de divers cas limites.

10. Partagez autant que possible

Les obstacles à la libre circulation de l’information créent des frictions, réduisent l’effervescence d’idées et le plus souvent en restreignant notre propre capacité à communiquer, vous finissez par vous tirer une balle dans le pied. C’est vrai en interne comme en externe. Quand c’est possible, partagez l’information autant que vous pouvez. Soyez ouverts par défaut. Cela signifie que vous devriez privilégier les standards ouverts, les formats ouverts et les systèmes ouverts aux solutions sur mesure, personnalisés ou uniques. Pour faciliter cela, préférez les normes sociales et culturelles aux contraintes techniques. Capturez et exposez le process de toute ce que vous faites. Ne le verrouillez pas à moins que vous n’ayez pas d’autre choix. Mieux encore, encouragez les autres à contribuer.

Example : Nous avions une implémentation interne pour le recueil de métadonnées d’un site GitHub Pages. Résultat, les utilisateurs ne pouvaient pas bénéficier de cette expérience localement quand ils prévisualisaient leur site, malgré le fait qu’il n’y avait rien de propriétaire à notre approche. Nous avons crée un plugin open-source pour répliquer cette expérience et nous avons fini par utiliser exclusivement cette implémentation. Résultat, l’environnement de développement local des utilisateurs se rapproche au plus près de celui de leur site en ligne et les anomalies sont détectées plus vite et corrigées lorsqu’elles sont découvertes.

GitHub Pages est loin d’être parfait, mais j’ai beaucoup appris en passant les trois dernières années à hacker un même produit (une éternité en années techniques) et davantage en hackant un projet open-source et des projets gouvernementaux auparavant. Ce sont les leçons que j’ai tirées de ce qui marche et, plus important, de ce qui ne marche pas. Cela m’a appris ce que je pense être le meilleur moyen de développer des produits, mais je suis sur qu’il y a encore beaucoup, beaucoup plus à apprendre. Quelles sont les règles qui dictent comment vous abordez un produit (ou comme je le pensais auparavant, un projet open-source) ?

  1. nom donné aux paquets logiciels dans l’écosystème du langage Ruby ↩