Auteur/autrice : Hadrien

Comme beaucoup j’aimerais contribuer à rendre le monde meilleur mais je n’ai que quelques heures par jour à y consacrer et pas beaucoup d’argent à investir : alors que faire ? 

Si vous êtes dans ce cas, rassurez vous vous n’êtes pas seul ! Mon objectif à travers cette série d’articles est de vous montrer qu’en trouvant d’autres personnes avec les mêmes contraintes et les mêmes aspirations, et une organisation appropriée, beaucoup de choses deviennent possible. Ne vous attendez pas à devenir multi-millionnaire (j’espère que ce n’était pas votre objectif principal) mais vous pourriez même projeter d’en vivre.

Savez vous pourquoi l’on trouve des logiciels open source, et pas des voitures ou des appartements open source… (même s’il existe des plans ici et là) ? C’est que l’investissement nécessaire pour développer un logiciel est à plus de 90% constitué par les salaires des équipes, et il y a donc un effet de levier très important entre les moyens à investir (hors salaires) pour développer un logiciel, et les résultats qu’on peut en attendre. En d’autre terme si une équipe de bénévoles développe un logiciel et trouve un grand nombre d’utilisateurs, le coût de revient par utilisateur est minime.

Partant de cette constatation, il me semble que les 2 modèles d’organisation les plus fréquents dans l’industrie du logiciel ne sont pas idéaux, et qu’il en manque un troisième qui serait un mix entre eux. Le premier modèle le plus fréquent c’est celui de la société privée créée par des petits génies du logiciel et financée par des business angels (des personnes riches et qui aiment la tech) et/ou des fonds spécialisés (des organisations qui mutualisent l’argent des précédents et sont spécialisés dans la détection et l’accompagnement des pépites de la tech). C’est le modèle de toutes les sociétés du logiciel connues de Google ou Facebook à la majorité des start-ups technologiques. L’avantage de cette organisation est de permettre une croissance rapide aux sociétés qui réussissent et une part importante dans de nouveaux marchés. Le modèle est attractif pour les fondateurs et les investisseurs, qui peuvent s’enrichir rapidement à condition de prendre des risques (seul 10 à 15% des projets réussissent même si d’autres disent que c’est plus).

Le deuxième modèle d’organisation fréquent est celui des communautés éditrices de logiciels libre. Les plus connues bénéficient en général d’un noyau dur de petits génies, bientôt rejoint par un grand nombre de fan plus ou moins productifs. Le secret de la réussite réside dans la bonne organisation de la communauté pour arriver à faire converger toutes ces énergies. De plus bien qu’ils aient renoncé à la propriété des logiciels développés, et ainsi attiré toute une communauté de développeurs, les fondateurs peuvent en vivre en proposant des services aux utilisateurs des logiciels libre. C’est ainsi que WordPress, le logiciel libre qui gère le contenu de 30% à 40% des sites webs dans le monde, est divisé entre une fondation (WordPress.org) et une entreprise (Auttomatic) qui gère le site wordpress.com et a été récemment valorisée à plus d’1 Milliard de dollars.

Mais ces deux modèles ne sont pas idéaux. D’une part le premier enrichit surtout les plus riches qui peuvent investir énormément au départ pour accélérer le développement de start-ups, et qui peuvent se permettre de prendre le risque de perdre 8 ou 9 de leurs investissements en échange d’un ou deux succès. Pour la plupart des fondateurs qui investissent leur temps et leurs économies dans ces projets le jeu est beaucoup plus risqué, et leurs employés même s’ils sont bien payés ne récoltent en général que quelques miettes du succès de l’entreprise. Le deuxième modèle n’est pas idéal non plus : pourquoi renoncer par idéal à la propriété de ce qu’on crée ? Le principe fondateur que le logiciel est un bien commun qui doit n’appartenir à personne pour bénéficier à tous n’est pas si évident pour la plupart d’entre nous. Il semble plus naturel au contraire qu’un bien qui a nécessité l’effort de dizaines, voire de centaines de personnes, mérite de leur rapporter de quoi se consacrer entièrement à leur passion, à condition bien sur qu’il rencontre un large public. Si les voitures ou les immeubles ne coutaient que la force de nos bras pour être fabriqués, verrait-on des voitures ou des appartements gratuits offerts au plus grand nombre ?

Il est possible de créer des communautés d’entrepreneurs, qui souhaitent mettre leurs efforts en commun comme pour un logiciel libre, mais souhaitent conserver et se partager la propriété du logiciel qu’ils produisent

A l’intersection de ces deux modèles, il est possible même si cela ne s’est pas encore vu à ma connaissance, de créer des communautés d’entrepreneurs, qui souhaitent mettre leurs efforts en commun comme pour un logiciel libre, mais souhaitent conserver et se partager la propriété du logiciel qu’ils produisent. S’ils suivent de bons principes d’organisation — les mêmes principes que pour développer un logiciel libre — ils pourront faire baisser leur besoin en investissement considérablement, et ainsi se passer en grande partie de business angels ou de fonds d’investissement. Pour cela il suffit de reprendre l’organisation des communautés du logiciel libre, en changeant légèrement le contrat auquel tout développeur et tout utilisateur souscrit. Bien sur le logiciel ne sera plus gratuit pour l’utilisateur final, mais cela n’est pas un problème fondamental, sauf pour ceux qui ne souhaitent pas sortir de l’idéal du bien commun. Pour ceux-là le logiciel libre est l’organisation adéquate. 

La difficulté principale de ce nouveau modèle est de trouver un moyen simple et unanimement accepté de se répartir la propriété des résultats. Pour être efficace, ce partage doit s’appuyer sur une règle claire et facile à comptabiliser, donc sans ambiguïté, et une bonne dose de transparence. A ce sujet les outils utilisés dans les communautés du libre bien qu’ils privilégient la transparence, ne sont pas exempts de relations de pouvoir et parfois d’opacité entre les « responsables » (« maintainers » en anglais) et les autres contributeurs, car ce sont eux qui décident dans quelle direction doit aller le projet et d’accepter ou non une contribution. Ces relations de pouvoir semblent assez inévitables dans tous les modèles d’organisation, et justifient qu’on mette en place des règles de partage de la propriété claires et efficaces. 

Le bon mix entre le système des entreprises et celui des communautés me semble donc être le suivant : 

Par exemple dans ce modèle 3 amis peuvent lancer un projet nécessitant 1000 heures de travail, trouver 7 autres contributeurs, et se répartir la propriété en fonction du temps passé. Certains de ces contributeurs fournissent un effort plus important, et rejoignent en cours de projet les 3 fondateurs comme « responsables » ou même « propriétaires » du projet. A l’issue de 5 mois de travail ceux qui ont fait un effort important (40 à 50 heures par mois) peuvent retirer 20 à 25% des parts, tandis que ceux qui ont une contribution plus modeste (10 heures par mois) auront chacun 5% des parts. S’ils conviennent ensuite de donner le logiciel en gestion à une entreprise créée par deux d’entre eux, chaque contributeur se verra reverser des droits en fonction de ses parts. Si par la suite certains d’entre eux continuent à faire évoluer le produit, les parts évolueront dans le temps et la rétribution de tous également.

Pour réaliser un projet de ce type nos 3 amis et leurs contributeurs devront utiliser un environnement de collaboration similaire à celui des communautés open sources, c’est à dire d’une part un service qui stocke et permet de faire converger les réalisations de chacun (le plus connu de ces outils de « gestion de sources » en 2020 étant GitHub), et d’autre part un outil d’animation de leur groupe de travail (l’un des outils de ce type les plus connus en 2020 étant Slack). Beaucoup d’autres outils de ce type existent, et il est même possible de s’en tenir à des échanges par emails et réunions téléphoniques, mais aucun outil existant en 2020 ne permet d’exécuter facilement les process (1), (2) et (3) ci-dessus. Ils devront également utiliser un cadre contractuel qui n’existe pas aujourd’hui, mais qui peut s’inspirer fortement de contrats existants dans le monde du libre ou celui des entreprises. 

Pour résumer cette première idée, il est possible mettre en place des outils logiciels juridiques permettant de créer et d’administrer tout nouveau projet logiciel sans apport financier, et de rétribuer les contributeurs en parts au lieu d’un salaire en suivant les processus (1), (2) et (3) ci-dessus. Ces outils peuvent rester très simples s’ils s’appuient sur les fonctionnalités qui existent déjà comme GitHub et Slack. Il est même amusant de constater que le développement de ces outils pourra être géré lui-même comme un projet du même type, dès qu’il atteindra un niveau de maturité suffisant. On est devant un processus de développement itératif qui utilise son propre résultat ! Cet outil sera également utilisable pour produire des résultats autre que le logiciel proprement dit, comme des contrats, des documents,… 

VOIRE GRAND, COMMENCER PETIT

Pour débuter un projet de ce type, il vaut mieux commencer par de petits pas, sans perdre de vue la vision d’ensemble. On pourrait comparer l’ambition de ce projet à une autre transformation culturelle et sociétale voulue par un précédent président Français même si elle n’a pas forcément bien marché : « permettre à chaque ménage d’être propriétaire, parce que la propriété est le rêve de chacun d’entre nous« . Aujourd’hui les logiciels que nous utilisons sont soit libres, soit entre les mains d’un petit nombre de propriétaires. Le développement d’un nouveau modèle permettrait de libérer un grand nombre d’énergies en rétribuant mieux les entrepreneurs et les porteurs d’idées innovantes, voire d’apprendre à développer des logiciels pour ses propres besoins, tout en gagnant un petit peu d’argent avec. C’est un peu comme si des amis décidaient de se construire un immeuble ensemble pour y habiter, tout en laissant 80% des appartements en location pour se constituer un revenu. Attention toutefois dans le domaine du logiciel, contrairement à l’immobilier, il est assez facile pour des entreprises concurrentes et des communautés du logiciel libre de copier les bonnes idées et de séduire une large clientèle plus rapidement que nos petits entrepreneurs. Il faudra se protéger de cette menace : nous y reviendrons.

Commençons par de petits pas donc. En 2018 nous avons essayé de monter un premier projet Rebindme (qui fait l’objet de ce site web), et nous avons échoué à mettre ce premier projet sur le marché pour deux ou trois raisons principales. D’une part le projet s’est avéré plus complexe que prévu, car il consistait à mettre en relation plusieurs communautés (des consommateurs, des PMEs et des contributeurs au projet), et surtout parce que nous n’avons pas réussi à monter une équipe capable de développer les premières versions du produit et intéressée par des ‘parts’ de l’entreprise plutôt qu’un salaire.

Vu d’aujourd’hui en 2020, ce premier projet était probablement un trop grand pas, et la technologie à utiliser mal choisie. Un projet innovant de ce type doit pouvoir apporter des résultats à ses contributeurs en 6 mois (12 au maximum), pas forcément sous forme de résultats financiers, mais au moins en trouvant ses premiers utilisateurs. Pour cela il existe des outils de développement logiciel assez simples à utiliser et à apprendre, open source eux-mêmes la plupart du temps : par exemple pour développer des applications web, l’environnement Django — appuyé sur le langage Python — semble bien adapté car très simple à utiliser par des novices. Cela permet de former rapidement des gens intéressés par un projet et de les rendre rapidement productifs, plutôt que d’aller chercher des gens compétents mais déjà très bien payés dans des sociétés privées.

Par ailleurs il est possible d’identifier de petits projets pour entamer l’aventure : des choses utiles qu’un site web peut aider un particulier à résoudre et qu’il est prêt à payer quelques Euros : suivre ses dépenses, optimiser son ordinateur, retrouver ses archives, gérer ses dossiers administratifs, créer une liste partagée pour ses cadeaux de Noël… On retrouve néanmoins beaucoup de données personnelles au centre de ces applications, et il sera nécessaire de fournir aux utilisateurs une garantie du bon usage de leurs données. On pourra également leur permettre d’installer le site web directement chez eux pour qu’ils n’aient pas à partager les données avec nous.  

A suivre : chapitre 2 – L’âge d’or du développement web c’est maintenant

(Suite du chapitre 1 – Inventons le logiciel dont vous êtes le héros )

Apprendre à créer ses propres applications web et se faire aider par une communauté spécialisée devient à la portée d’un très grand nombre de personnes.

Comment sont consommées la plupart de ces petites applications pour les particuliers (ou ‘apps’) aujourd’hui ? Principalement sous deux forme : des apps dites ‘mobiles’ nativement développées pour smartphones et tablettes, et des sites web consultables à partir de tout type d’appareils. Depuis quelques années la différence entre ces deux catégories d’apps s’estompe : statistiquement les apps ‘mobiles’ sont préférées par les utilisateurs mais leurs avantages principaux comme la mobilité, la rapidité ou une meilleure expérience utilisateur sont maintenant égalés par les sites web de dernière génération. Ceux-ci sont accessibles sur mobile dans un format adapté dit ‘responsive’, et bénéficient de navigateurs web plus rapides et capables de donner une expérience ‘enrichie’ aux utilisateurs proche de celle des app mobiles. Les équipes qui font progresser des navigateurs comme Chrome (Google) ou Edge (Microsoft) ont joint leurs forces pour progresser plus vite (ils s’appuient sur la même technologie open source Chromium), et sont concurrencé de loin par Apple (Safari) et Mozilla (Firefox) qui ont leur propre technologie mais font des efforts similaires. On peut dire qu’aujourd’hui l’avantage de développer des apps ‘mobiles’ est fortement concurrencé par la facilité de développer des ‘apps web’.

Pour ceux qui font le choix de développer des apps web, l’un des inconvénients est l’évolution permanente des technologies dans ce domaine — a ce sujet voir cette infographie impressionnante qui s’arrête malheureusement en 2012 ou celle ci qui date de 2020. Le choix des bonnes technologies pour développer une app web doit être adapté à la complexité et la durée du projet  mais il y a quelques incontournables comme JavaScript et ses librairies comme React ou jQuery pour l’expérience utilisateur, ou comme Rails ou Django pour la facilité de développement côté serveur. Ce dernier environnement, Django, est lui même basé sur un langage récent et très facile à apprendre, Python, assez proche du langage naturel (en anglais!). D’autres technologies sont nécessaires pour développer une application complète (une base de donnée, un système de tests automatiques, un serveur web ou une plateforme de déploiement…) mais nous y reviendrons.

Les technologies utilisées par deux sites webs connus : Airbnb, the world’s most well-known hospitality service that helps millions of people find rental apartments and short-term lodging, is largely based on Ruby on Rails., while Instagram, a mainstream social networking application, is built with Python. (Source: RubyGarage.com)

Toutes ces technologies ont gagné rapidement en popularité ces dernières années si bien qu’une large communauté s’est développée autour d’elles, et que de nombreux contenus de formation et forums de discussions existent aujourd’hui pour s’auto-former et se faire assister. Le site web spécialisé le plus connu, StackOverflow  reçoit plus 100 Millions de visiteurs par mois (il fait partie des 50 sites les plus visités au monde) et vient de lever 85 Millions de Dollars en Juillet 2020 pour continuer à se développer. Depuis 1 à 2 ans le terme d’environnement ‘low-code’ ou ’no-code’ devient également populaire, avec l’apparition de nouvelles offres comme AppSheet racheté par Google ou d’autres. Mais leurs capacités sont encore assez limitées. Apprendre à créer ses propres applications web et se faire aider par une communauté spécialisée devient donc à la portée d’un très grand nombre de personnes.

Il existe aujourd’hui des environnements de développements qui permettent de décrire assez intuitivement n’importe quel idée d’app en 3 étapes.

Après avoir expérimenté Rails il y a 10 ans, j’ai donc pu profiter du confinement en 2020 pour débuter en Python et Django. On retrouve dans ces deux environnement de développement web les mêmes éléments de base, et notamment le concept que l’inventeur de Rails, David HH, a nommé ‘échafaudage’ (scaffolding). Ce concept — ou plutôt cette bonne pratique — permet de créer facilement de nouvelles applications en générant automatiquement tous les éléments nécessaires à son fonctionnement, tout en gardant ces éléments bien structurés pour pouvoir ensuite les faire évoluer un par un ‘à la main’, c’est à dire en modifiant leur code source. Contrairement à cette bonne pratique, les environnements de génération précédente — comme Windev ou Deplhi — permettent de créer rapidement des applications mais leur modification ultérieure devient vite un vrai casse tête, car le code source de ces éléments n’est pas pensé pour être modifié ‘à la main’.
Que ce soit avec Rails ou avec Django les grandes étapes de la création d’une application web sont sensiblement les mêmes : d’abord la création d’une application vide (ce qui crée tout de même toute la structure nécessaire, et notamment une base de données et un mini serveur web suffisant pour le développement), puis sans ordre particulier

(1) l’édition d’un modèle de données qui sera au fur et à mesure importé sous forme de tables dans la base de données,

(2) la création de pages web qui présentent les données à l’utilisateur et permettent de les manipuler, et

(3) l’enrichissement des éléments du modèle pour qu’ils réagissent de manière appropriée lorsque l’utilisateur les manipule (on parle de ‘comportement’ ou de ‘logique métier’ de ces données, et ces comportements sont codés comme des fonction en Python pour Django, ou en Ruby pour Rails).

Ces étapes étant en nombre limité le développement se faire de manière assez itérative, facilitant l’apprentissage pour les développeurs débutants.

L’intérêt de ces environnements c’est de pouvoir décomposer et décrire de manière assez intuitive n’importe quelle application suivant ces 3 éléments. Prenons l’exemple de l’outil logiciel discuté dans le premier chapitre (celui qui permet à un groupe d’entrepreneurs de collaborer tout en se partageant la propriété intellectuelle de leur résultat). La première idée (ou ‘scénario’) qui vient à l’esprit est le suivant : lorsqu’un utilisateur de l’outil a une idée de nouveau projet et souhaite y collaborer avec d’autres, il doit pouvoir documenter son idée rapidement et inviter tout d’abord ses amis à lui donner leur opinion en privé et à participer au développement. Pour cela, cet utilisateur va devoir (1) interagir avec les modèles Projet — pour stocker le nom, le statut (ce n’est encore qu’un ‘brouillon’), une icône ou une image et différentes sections décrivant le projet — et Utilisateur — pour stocker une liste d’Amis invités à échanger sur un projet grâce à (2) une page web qui permettre de créer ou de modifier un Projet et de sélectionner d’autre Utilisateurs parmi une liste d’Amis avec qui partager ce ‘brouillon’ de projet. On devra enfin (3) vérifier que chaque Utilisateur ne doit avoir accès qu’à ses propres projets ou ceux auxquels il est invité, même s’il intercepte un email d’invitation qui ne lui est pas destiné.

Ce n’est qu’un scénario, et une application en comporte généralement des dizaines, mais le principe reste le même pour les suivants, et petit à petit le modèle de données (1), les pages web (2) et les comportements (3) vont s’enrichir en essayant de les conserver les plus simples possibles.

On ne parle ici que des environnements de développement pour apps web. Rappelons nous que pour l’instant en 2020, les apps ‘mobiles’ représentent aussi une grande part du marché, mais nous verrons que les environnements dédiés d’Apple (XCode et le langage Swift) et de Google (Android Studio et les langages Java, C++ et Kotlin) décomposent les applications ‘mobiles’ essentiellement dans les mêmes 3 éléments. Cette décomposition en 3 catégories d’éléments est généralement valable dans beaucoup de domaines, et désignée sous le nom de MVC « Modèle – Vue – Contrôleur ». Nous pourrons donc réutiliser les mêmes idées pour développer des apps ‘mobiles’

A suivre : Chapitre 3 : Apprendre en réalisant des projets concrets

« Ne me donne pas de poisson, apprend moi plutôt à pêcher » Phrase de Mao Tsé Toung (ou de Confucius, à vous de choisir)

(Suite du chapitre 2 – L’âge d’or du développement web c’est maintenant)

Si le développement d’applications semble réservé à un petit nombre de geeks, c’est certainement à cause de la mythologie qui entoure la figure du développeur, tel un sorcier, adepte des langages les plus ésotériques, choisi depuis l’enfance pour son talent et sa passion des machines, héritier d’un savoir transmis par ses pairs au cours de longues nuits de chats et de pages de forums sybillines…

En réalité l’art de coder est ouvert à tous, et probablement le meilleur moyen de dompter la technologie que nous utilisons quotidiennement. Malheureusement il est souvent enseigné de manière théorique et sur des exemples simples, à la manière d’un jeu. Si cet aspect ludique permet d’ouvrir l’art de coder à un plus grand nombre, il reste difficile de passer ensuite à l’application réelle, et à la création de logiciels utiles pour soi ou pour le plus grand nombre.

Et si au lieu de cela nous étions capables d’apprendre à coder au fil de l’eau, en fonction de nos idées et de nos besoins ? Et d’appliquer immédiatement nos nouvelles connaissances à des projets concrets ? Un exemple : j’aimerais trouver une application qui m’apprenne à faire des Sudoku avancés, mais sans me donner la solution, juste en me fournissant des indices lorsque je sèche pendant plus de 30 secondes. Cette application n’existe pas, et pourtant je suis sur qu’elle pourrait séduire beaucoup d’autres amateurs de Sudokus. Comment puis-je apprendre à créer cette application ?

Comme nous l’avons vu au chapitre précédent, je dois commencer par décrire plus précisément mon idée, et ensuite pour chaque scénario à implémenter choisir les bons composants technologiques, en me laissant guider par mon environnement (Django, Rails,…) qui me propose presque toujours une architecture par défaut. Il y aura souvent des composants que je ne connais pas encore, mais que je peux apprendre à utiliser au fil de l’eau.

Peut-être demain disposerons nous pour cela d’environnements dotés d’intelligence artificielle auxquels il suffira que j’explique mon idée d’application pour que celle-ci apparaisse sous mes yeux sans que j’aie besoin d’écrire une seule ligne. La parole vague et le geste auront alors remplacé l’écriture chirurgicale de dizaines voire de milliers de lignes de code ! Pourquoi pas ? Ce jour là l’imagination n’aura plus de limites. Mais aujourd’hui il faut en passer par l’écriture de code, et pour cela rien ne vaut l’aide de mes pairs qui sont passés par là avant moi.

En effet les premières sources d’enseignement pour ceux comme moi qui souhaitent développer leurs applications, sont d’abord le condensé de savoir laissé par nos pairs dans des documentations en ligne [1] ou dans des vidéos d’explications, et ensuite les forums [2] où d’autres ont posé les mêmes questions avant nous. Souvent il est donc suffisant de suivre les traces de nos prédécesseurs pour faire les bons choix.

Au fil du développement d’une application il y a plusieurs types de questions que j’essaye de résoudre : (1) Quels composants utiliser pour réaliser telle fonction ? (2) Comment utiliser ce composant ? (3) Que veut dire ce message d’erreur ? ce qui équivaut à la question « Pourquoi ce que j’ai fait ne fonctionne pas ? » 

Pour la première de ces questions (« quels composants utiliser ? ») il faut parfois chercher un peu plus longtemps. Les cours théoriques, les vidéos d’exemples et certaines parties de la documentation en ligne, sont faits pour vous donner cette culture qui vous permettra ensuite de concevoir seul l’architecture de ce que vous imaginez. Si je veux absolument travailler seul il faudra que je prenne le temps de parcourir ces contenus, d’apprendre l’existence de tel ou tel composant et ce que je peux faire avec. Mais je peux aussi choisir d’assembler ou de rejoindre une équipe, et bénéficier de la connaissance des autres.

Il me semble ainsi que le rôle d’ « architecte logiciel » peut jouer un rôle déterminant dans le développement collaboratif d’applications par le plus grand nombre. Celui-ci peut rapidement apporter sa culture technologique pour convertir les scénarios imaginés par le groupe en architectures logicielles. Beaucoup de théoriciens planchent sur ce domaine depuis avant l’invention de l’informatique pour trouver les moyens de cartographier exactement l’architecture d’un système technologique : Merise, UML, SysML… Je ne parle pas de cela. L’architecte peut aussi plus simplement guider le développeur en lui expliquant quels composants utiliser pour réaliser un scénario et comment il pense qu’il faudrait les relier entre eux. C’est une discussion et un enseignement plutôt qu’une relation maitre – esclave. Le but est que le développeur entrevoie les différents composants qu’il peut mettre en oeuvre, et fasse ensuite ses propres choix. Ainsi l’architecte apporte très rapidement une valeur importante au groupe, et peut apporter cette valeur à un grand nombre de développeurs sur un ou plusieurs projets.

A cette approche que je réserverais plutôt pour le début d’un projet ou pour des scénarios innovants, on pourrait ajouter la possibilité de créer un chemin d’apprentissage pour les développeurs qui souhaitent rejoindre un projet en cours de route. Un peu comme ces nouveaux colons qui arrivaient en Amérique, et avant de trouver leur place au soleil, devaient parcourir le territoire entre leur port d’arrivée et leur village de destination, et apprendre au passage à connaitre ce nouveau territoire, ses habitants et leurs règles [3]. Il me semble qu’il serait facile de créer ces chemins de découverte du code créé par une équipe en retraçant pour le nouvel arrivant l’ordre d’arrivée des différents composants, et en lui proposant de s’entrainer en codant lui-même certains scénarios déjà réalisés. De cette manière il arriverait ensuite rapidement et préparé au mieux à participer au développement de nouveaux scénarios. De plus la création de ce parcours pourrait être automatisée en utilisant l’historique du code et les scénarios de test disponibles.

(A suivre…)

Notes

[1] Exemples de documentation: Django : https://docs.djangoproject.com/; Rails : https://guides.rubyonrails.org/; Python : https://www.w3schools.com/python/; Ruby : https://www.ruby-lang.org/fr/documentation/

[2] Exemple de forums: https://stackoverflow.com/questions/tagged/django

[3] Voir à ce sujet des curiosités comme le chapitre 2 de ce livre de 1884 sur Les Français en Californie.