L'artisan et son atelier

Lors de sa formation dans une école, l'apprenti menuisier aura la possibilité d'utiliser tout un tas d'outils de complexité variable (scies, rabots, perceuses, défonceuses, ...).

L'atelier de l'école est donc le premier atelier de notre apprenti, celui dans lequel il n'aura pas choisi les outils qu'il utilisera, ce qui est normal puisqu'il ne connaît pas, à son arrivée, leur manipulation, leurs caractéristiques et leurs variantes.

Il est également possible que, dans le but d'une formation généraliste au métier de menuisier, l'école ait investi dans des outils qui ne soient pas les plus sophistiqués, car trop chers ou trop complexes pour un usage par des apprentis. Ces outils choisis sont cependant suffisamment perfectionnés et de qualité suffisante pour permettre la réalisation des pièces dans de bonnes conditions.

Il est par ailleurs important que l'apprenti comprenne les tâches de base, même si plus tard il travaille dans un environnement ou certaines d'entre elles sont automatisées. Cette compréhension, passant par la réalisation de ces tâches, est ce qui lui permettra de pouvoir avoir un regard critique sur une réalisation, la sienne, celle d'un autre ou d'une machine.

L'agencement de l'atelier sera sûrement de telle sorte que plusieurs apprentis puissent pratiquer en même temps les mêmes outils. Il ne sera donc pas optimisé pour un travail précis, c'est-à-dire la création de certains types de pièces ou d'assemblages.

Une fois l'apprenti devenu véritable artisan, son atelier reflétera sa façon de travailler, l'usure témoignera des outils dont il se sert le plus... De plus, il organisera son espace et agencera ses outils en fonction de la pièce à fabriquer et plus généralement du travail qu'il prévoit.

Même si son apprentissage aura été commun avec d'autres apprentis, son expérience et sa réflexion feront de lui un artisan unique par ses méthodes, son tour de main, ses pratiques en général.

Cela aura été rendu possible par la liberté qu'il avait de prendre des initiatives pour adopter de nouveaux outils, de nouvelles pratiques. Toute la différence avec le travail à la chaîne.

Si on considère que le développeur de logiciel est aussi un artisan, un homme de l'art, qui fait évoluer ses pratiques par l'expérience et la réflexion, on comprend que l'atelier de cet artisan n'est pas une forge dans leur forme actuelle (regroupement d'outils sous un chapeau appelé "projet").

Ces forges actuelles correspondent à l'atelier dans lequel l'apprenti est formé: tout est déjà installé, des outils répondant aux besoins moyens sont disponibles, ils sont agencés d'une certaine façon, fixée.

Dans un tel atelier "standard", le véritable artisan développeur sera bridé et ne pourra faire évoluer ses pratiques pour créer un environnement le plus propice à la réalisation efficace de ses travaux.

La notion de "projet" dans les forges actuelles correspond à un regroupement d'outils dans un espace réservé au développement d'un logiciel, d'un article, ...

Or, il me semble que ce regroupement devrait plutôt se faire dans un "atelier", symbolisant l'espace que le développeur organisera à sa façon pour son travail. A lui de voir s'il veut développer plusieurs logiciels dans le même atelier, avec les mêmes outils agencés à sa façon. Il peut aussi accueillir d'autres développeurs, en leur donnant le droit ou non d'utiliser certains outils.

Rien ne devrait empêcher de commencer un travail (un logiciel, un article ou autre artéfact) dans un atelier et le continuer dans un autre qui contiendrait d'autres outils plus adaptés à de nouvelles évolutions prévues pour ce travail: nouvelle organisation, diffusion plus large, ...

Un atelier ou une partie d'un atelier, y compris son agencement devrait pouvoir être dupliqués, ce qui s'avérerait utile lors d'un fork d'un logiciel par exemple, ou bien pour faire évoluer un atelier pour une partie des logiciels qui y sont développés mais pas pour d'autres.

Exemple de scénario: Un développeur commence le développement d'un logiciel dans son atelier habituel. Si une communauté commencé à se former autour de ce logiciel, un atelier peut être créé ou cloné à partir de l'atelier du développeur original, et la communauté peut à son tour agencer le nouvel atelier pour faire face à ses nouveaux besoins.

Je pense qu'il faudrait remplacer les notions de forge et de projet par les notions d'atelier et d'artéfact, les forges actuelles devenant alors des ateliers "standards". Cela aurait l'avantage de séparer clairement les outils de l'objet développé (artéfact), donc séparer les outils de l'information qu'ils permettent de stocker et manipuler. Dans notre analogie avec l'atelier du menuisier, j'aimerais par exemple pouvoir remplacer une scie par une autre scie plus puissante ou plus sûre: la fonction resterait la même mais je gagnerais en efficacité.

Cette distinction plus claire entre données et outils permettrait à terme de pouvoir plus facilement avoir des systèmes de migration d'un outil vers un autre. Cela nécessite que les outils partagent des concepts communs.

Le remplacement d'un outil par un autre, la migration de l'information d'un outil vers un autre, la possibilité de proposer des ateliers reflétant certains processus de développements et dans lesquels il ne resterait plus qu'à indiquer quels outils utiliser, tout cela nécessite de pouvoir représenter les informations relatives à un artéfact.

Les concepts du web sémantiques (ontologies, relations, ...) seront utiles pour avancer dans cette direction. Par ailleurs, des annuaires des ateliers et des artefacts pourraient s'appuyer sur ces représentations pour pouvoir faire des recherches précises sur les logiciels développés, par exemple. Ainsi, il deviendrait facile de répondre à des questions comme:

• De quels logiciels dépend ce logiciel ?
• Quels logiciels sont développés à l'aide de cet outil ?
• Quels ateliers regroupent plus de N développeurs ?
• A quels ateliers participe tel développeur ?
• ...

Il devient aussi possible, en s'appuyant sur des concepts communs, de tisser des liens formels entre artéfacts, même s'ils se trouvent dans des ateliers différents. Par exemple, on pourrait référencer un bogue d'un logiciel comme source identifiée d'un bogue dans un autre logiciel. On peut aussi penser aux liens de filiation créés suite à des forks ou des découpages de logiciels, ...

La possibilité de mettre en place ses ateliers, d'y inviter d'autres développeurs, etc. sera sans nulle doute facilitée par l'utilisation des fameux clouds, notamment les "open clouds".

Une remarque: Chaque artisan développeur n'apprend pas le métier qu'au travers des outils mais plutôt, voire surtout, au contact d'autres artisans, dans une relation de compagnonnage, dans laquelle chacun est influencé par l'autre pour faire évoluer ses pratiques, ses outils, se perfectionner, ...

L'atelier de l'apprenti n'est donc pas forcément unique; l'apprenti peut apprendre dans plusieurs ateliers de "maîtres", jusqu'au jour où il créera ses propres ateliers (tout en continuant de travailler éventuellement dans des ateliers d'autres artisans).

Cette possibilité en quelque sorte d'ubiquité démultiplie les occasions d'apprendre auprès d'autres artisans, et de transmettre entre artisans: Les méthodes et outils rencontrés dans un atelier par un artisan peuvent ensuite être proposés et appliqués dans un autre atelier auprès d'autres artisans. Je pense qu'il ne s'agit donc ni plus ni moins de construire et maintenir des circuits de transindividuation.