Software Carpentry ou la transmission de bonnes pratiques en informatique

Avec l’augmentation de la capa­ci­té des ordi­na­teurs et de la qua­li­té des algo­rithmes, l’informatique prend une place de plus en plus impor­tante dans la vie de tous les jours, mais aus­si dans la recherche. Cela est ren­du aus­si pos­sible grâce à la pro­gram­ma­tion et aux amé­lio­ra­tions des lan­guages, des outils et des pra­tiques. Les déve­lop­peurs sont deve­nus plus pro­duc­tifs.

Mais l’impact sur les scien­ti­fiques est plus miti­gé. En effet, la pro­duc­tion de nou­veaux résul­tats est ralen­tie par le temps néces­saire pour écrire, tes­ter, débug­ger, ins­tal­ler et main­te­nir des logi­ciels. Et la plu­part des scien­ti­fiques n’ont jamais appris com­ment faire cela effi­ca­ce­ment. Ils peuvent avoir sui­vi des cours géné­raux d’introduction à la pro­gram­ma­tion ou aux sta­tis­tiques. Mais ils n’ont que rare­ment enten­du par­ler de ges­tion­naire de ver­sion, ou com­ment trans­for­mer les der­nières com­mandes exé­cu­tées en un script réuti­li­sable. Ils passent ain­si des heures à faire des choses qui peuvent être faites en quelques minutes, avec une repro­duc­ti­bi­li­té qua­si-nulle. Ou pire, ils ne le font pas car ils ne savent pas par où com­men­cer.

Vous vous retrou­vez dans cette des­crip­tion, et vous vou­lez chan­ger vos pra­tiques pour faci­li­ter et amé­lio­rer votre recherche ? Vous tra­vaillez avec des scien­ti­fiques dans ce cas là et qui veulent chan­ger ? Soft­ware Car­pen­try pour­rait vous aider.

Software Carpentry

Soft­ware Car­pen­try est une orga­ni­sa­tion béné­vole fon­dée en 1998. Son but est de rendre les scien­ti­fiques plus pro­duc­tifs et d'améliorer la repro­duc­ti­bi­li­té de leur tra­vail en leur appre­nant des com­pé­tences basiques en pro­gram­ma­tion, comme :

  • Les bases de la pro­gram­ma­tion struc­tu­rée en Python ou R
  • Le contrôle de ver­sion avec git
  • L’automatisation de tâches avec Unix shell

 

Nombre cumu­la­tif de scien­ti­fiques for­més par Soft­ware Car­pen­try [1]

Le conte­nu des cours est orien­té vers les cher­cheurs avec une péda­go­gie adap­tée et vrai­ment réflé­chie. Le but est donc de pro­mou­voir l’autonomisation mais aus­si la repro­duc­ti­bi­li­té en recherche, en leur fai­sant adop­ter des tech­niques et des outils stan­dards dans l’industrie du logi­ciel.

Ces cours sont gérés selon le prin­cipe de l’open access. Ils sont donc libres et consul­tables par n’importe qui. Mais, la base de l’enseignement repose sur l’organisation de work­shops courts et inten­sifs, ani­més par des for­ma­teurs “asser­men­tés” béné­voles, par­tout dans le monde. Tout labo­ra­toire ou uni­ver­si­té peut orga­ni­ser un work­shop.

A quoi res­semble un work­shop "stan­dard" sur deux jours ?

  • Matin du pre­mier jour : Unix shell, avec pré­sen­ta­tion d’une dou­zaine de com­mandes basiques. L’objectif est d’introduire l’idée de com­bi­ner des outils simples (via pipes, boucle, filtre,…)
  • Après-midi du pre­mier jour : pro­gram­ma­tion en Python (ou par­fois R) pour mon­trer quand, pour­quoi et com­ment construire des pro­grammes étape par étape en fonc­tions com­pré­hen­sibles, réuti­li­sables et tes­tables
  • Matin du second jour : ges­tion­naire de ver­sion comme git en insis­tant sur l'importance de l'utiliser, plu­tôt que créer des réper­toires nom­més “final”, “really_​final” et pour col­la­bo­rer de façon plus effi­cace
  • Après-midi du second jour : appro­fon­dis­se­ment du lan­gage de pro­gram­ma­tion ou intro­duc­tion aux bases de don­nées et à SQL

Les work­shops sont basés sur la pra­tique par les élèves pour faire pas­ser des concepts plus larges, mal­gré des temps réduits. Le suc­cès des work­shops vient aus­si de plu­sieurs tech­niques mises en place : boucle de réac­tions (en temps réel pen­dant le work­shop, mais aus­si avant et après), live-coding, ouver­ture sur tout (suc­cès, échec, conte­nu des cours, …), déve­lop­pe­ment col­la­bo­ra­tif des cours, uti­li­sa­tion quo­ti­dienne par les for­ma­teurs de ce qui est ensei­gné, prise de note col­la­bo­ra­tive, pro­gram­ma­tion par paire,…

Trou­vant la phi­lo­so­phie inté­res­sante, j’ai vou­lu orga­ni­ser un work­shop au sein de mon labo­ra­toire (à Cler­mont-Fer­rand), de pré­fé­rence en fran­çais. J’ai donc regar­dé quels étaient les  for­ma­teurs “asser­men­tés” pos­sibles. Ils sont nom­breux aux États Unis, au Cana­da et en Angle­terre. Mais en France (il y a un an), il n'y en avait que 3 : 2 à Paris et 1 à Lyon, com­pli­quant l’organisation d’un work­shop dans mon labo­ra­toire. Devant le manque de for­ma­teurs sur le ter­ri­toire fran­çais. j’ai alors vou­lu rejoindre cette orga­ni­sa­tion.

Devenir formateur

En juin der­nier, je me suis donc ins­crite. La for­ma­tion a démar­ré en octobre, pour 12 semaines. Elle ne por­tait pas tant sur le conte­nu des work­shops. C’est plu­tôt une intro­duc­tion à la recherche moderne pour l’éducation et les pra­tiques d’enseignement.

Com­ment s’est dérou­lée la for­ma­tion ?

Durant 12 semaines, j’avais une heure de cours à suivre chaque semaine et ensuite des “devoirs” à réa­li­ser pour la semaine sui­vante. Les cours étaient en anglais et se fai­saient à dis­tance. Ether­pad était uti­li­sé pour la prise de notes col­la­bo­ra­tives et pour poser des ques­tions au for­ma­teur. Les devoirs étaient sou­mis via Piaz­za. Et pour favo­ri­ser les échanges et avoir des visions dif­fé­rentes, les devoirs étaient com­men­tés par tous. Cer­tains devoirs repo­saient aus­si sur des simu­la­tions de cours avec du live-coding à dis­tance (via Han­gout). Cet exer­cice, par­ti­cu­liè­re­ment dif­fi­cile, est très for­ma­teur.

L’obtention de la cer­ti­fi­ca­tion (un des buts de la for­ma­tion) pas­sait par une phase d’évaluation. D’abord, par les devoirs, pas direc­te­ment (pas de notes), mais par la régu­la­ri­té et le sérieux. L’évaluation prin­ci­pale repo­sait sur la pré­pa­ra­tion d’une des leçons (3h) pro­po­sées par Soft­ware Car­pen­try dans les work­shops, la pro­po­si­tion d’un exer­cice pour cette leçon et la res­ti­tu­tion (en anglais) de 5 minutes de cette leçon devant un for­ma­teur expé­ri­men­té. Avec un peu de pré­pa­ra­tion, ce n’était pas si com­pli­qué. L’évaluation ne donne pas lieu à nota­tion mais sert sur­tout à esti­mer si la phi­lo­so­phie de Soft­ware Car­pen­try et de l’enseignement est assi­mi­lée.

Ain­si, la for­ma­tion m’a ini­tiée aux bases de la psy­cho­lo­gie de l’éducation, à la concep­tion de conte­nu édu­ca­tif (QCM, concept map, …) et l'application à l'enseignement la pro­gram­ma­tion. Des choses essen­tielles pour toute per­sonne vouée à ensei­gner l’informatique, mais qui ne sont pas trans­mises aux nou­veaux ensei­gnants. Ca a été aus­si l’occasion de m’initier à des outils comme les note­books Jupy­ter, la prise de notes col­la­bo­ra­tive avec Ether­pad, …

J’ai ain­si obte­nu la cer­ti­fi­ca­tion. Je fais main­te­nant par­ti des quelques for­ma­teurs fran­çais.

Pour l’instant, je n’ai pas eu l’occasion de par­ti­ci­per à un work­shop. Mais j’ai pu appli­quer et véri­fier l'impact des concepts et des outils acquis durant la for­ma­tion. En effet, j'enseigne depuis deux ans (donc avant et après la for­ma­tion) à l'IUT de bio­in­for­ma­tique d’Aurillac. Cette année, j'ai mis en place des cours QCM régu­liè­re­ment pen­dant les cours (comme recom­man­dé). Ces QCM per­mettent de main­te­nir l'attention des étu­diants, de les ame­ner à réflé­chir d'avantage sur le conte­nu du cours mais aus­si de véri­fier en temps réel l'acquisition des notions abor­dées. J'ai aus­si mis en place du live-coding, en me basant sur des note­books Jupy­ter. Les retours des étu­diants ont été glo­ba­le­ment posi­tifs et j'ai pris beau­coup plus de plai­sir que l'année pré­cé­dente à ensei­gner.

Conclusion

Soft­ware Car­pen­try est un pro­gramme (très inté­res­sant) pour apprendre aux cher­cheurs du monde entier les com­pé­tences tech­niques néces­saires pour amé­lio­rer leur tra­vail et leur per­mettre de faire plus en moins de temps et plus faci­le­ment.

Apprendre à deve­nir for­ma­teur pour l'association Soft­ware Car­pen­try a été pour moi une expé­rience très inté­res­sante et enri­chis­sante. Je ne peux que vous encou­ra­ger à la suivre à votre tour. Pour­quoi ?

  • Pour opti­mi­ser le tra­vail des scien­ti­fiques en leur trans­met­tant de bonnes pra­tiques d'usage de l'informatique
  • Pour amé­lio­rer votre réseau (pen­dant les work­shops)
  • Pour apprendre de nou­velles choses, sur­tout en péda­go­gie
  • Pour ensei­gner et deve­nir un super ensei­gnant
  • Pour favo­ri­ser la diver­si­té et l'origine des for­ma­teurs
  • Pour le fun

Pour ceux que ne se sentent pas l’âme d’enseigner, amé­lio­rez le monde de la recherche et la vie de vos collaborateurs/​coworkers : orga­ni­sez des work­shops Soft­ware Car­pen­try !

 

Je remer­cie Fabrice, Estel et Bun­ny pour la relec­ture et leurs com­men­taires

 

[1] Wil­son G. Soft­ware Car­pen­try : les­sons lear­ned. F1000Research 2016, 3:62 (doi : 10.12688/f1000research.3–62.v2)



Pour continuer la lecture :


Commentaires

3 réponses à “Software Carpentry ou la transmission de bonnes pratiques en informatique”

  1. Avatar de Lansana
    Lansana

    Bon­jour

    Ton artuicle est inter­es­sant. Ce serait bien que les nou­veaux ensei­gnants apprennent cette tech­nique afin que les eleves ou etu­diants puissent avoir plus de plai­sir a apprendre. Car il y a vrai­ment cer­tains ensei­gnants qui ne doivent pas ensei­gner, vu que leur ensei­gne­ment est ennuyant et donne envie de dor­mir.
    Encore une fois mer­ci de par­ta­ger ton expe­reince sur ce site 😀

  2. Bon­jour. Il faut com­prendre que la concep­tion de logi­ciel n'est pas le coeur de métier des scien­ti­fiques. Ils ont plu­tôt pour cou­tume de délé­guer cette tâche à des pres­ta­taires externes.

    1. C'est loin d'être le cas pour un aspect majeur du métier de cher­cheur usant de l'informatique : pro­duire et dis­tri­buer un code « preuve de concept » ayant per­mis la rédac­tion d'un article.

      Oui, dans un monde par­fait, chaque cher­cheur est en contact avec une équipe de purs infor­ma­ti­ciens, qui se plient en quatre pour implé­men­ter, docu­men­ter, dis­tri­buer et main­te­nir « cette nou­velle idée qui devrait résoudre ce pro­blème ».

      En vrai, le cher­cheur moyen a appris à coder tout seul ou dans une for­ma­tion courte et expé­di­tive.
      Le pro­gramme est écrit rapi­de­ment, car ce sont les résul­tats qui comptent.
      La por­ta­bi­li­té ? La dis­tri­bu­tion ? La Doc ? Pas le temps, on a une publi à finir, figu­rez-vous !

      Cet article met en avant une ini­tia­tive fort inté­res­sante : étendre la for­ma­tion des scien­ti­fiques de quelques heures, non pas pour leur apprendre uni­que­ment les bases obs­cures d'un énième outil ou para­digme,
      mais sur­tout pour intro­duire des notions de base en ges­tion de pro­jet, et pré­sen­ter des outils pour les encou­ra­ger à ne pas réin­ven­ter la roue.

      Tout le monde n'a pas les moyens de faire appel à un infor­ma­ti­cien pour gérer un bout de code de 1000 lignes écrites et débug­gées qua­si­ment d'une seule traite.

      L'objectif n'est pas de peu­pler la recherche d'une armée de concep­teur logi­ciel che­vron­nés,
      mais de mini­mi­ser la dette tech­nique en atten­dant une pro­chaine géné­ra­tion,
      cor­rec­te­ment édu­quée à pro­pos des pro­blèmes infor­ma­tiques.

      Autre­ment dit, sau­ver les meubles en atten­dant les secours.

      Per­son­nel­le­ment, j'ai bien envie de regar­der du côté de la for­ma­tion,
      ça me semble être vache­ment rigo­lo, et si ça peut per­mettre l'organisation d'un work­shop…
      Je signe !

Laisser un commentaire