Présentation de la démarche qui nous a amené à mettre en place un système de gestion des badges par la rédaction de wikis sur le sites des Brickodeurs plutôt que de passer par une démarche déclarative auprès des animateurs et des membres.

1. Kit pédagogique de
démarrage du hackathon
Appliqué aux Brickodeurs pour identifier les compétences des
Brickodeurs et les inciter à partager leur compétence.

2. Mise en œuvre du kit de démarrage à partir
d’un exemple
• Afin d’illustrer comment utiliser le kit de démarrage d’un hackathon,
nous allons l’illustrer à partir d’un exemple concret.
• Il s’agit d’un kit de démarrage, c’est-à-dire qu’il sert à amorcer la
démarche pour identifier la problématique et ses acteurs pour
commencer à imaginer des pistes de solutions.
• La partie « Réalisation » consiste à définir le plus clairement possible
la solution envisagé sans rentrer dans les aspects (trop) techniques.

3. Brief de design thinking
• Pourquoi ? Problème :
• Les animateurs du club ne savent pas qui fait quoi au sein des projets du club,
ni qui sait quoi, ni comment contacter un tel ou un tel. Ils doivent passer par
Christophe ou attendre la prochaine réunion pour avoir leur réponse.
• Nous ne pouvons pas mettre en valeur ce qu’apprennent et ce que font les
Brickodeurs auprès de leurs parents et du public.
• Qui ? Les acteurs du problème :
• Les animateurs, les membres adhérents, les parents.
• Quoi ? Le But
• Disposer d’un moyen de savoir qui fait quoi au sein de Brickodeurs : quel
projet en cours, quelle équipe, quelle compétence disponible ?
• Possibilité de l’intégrer dans l’existant (site brickodeurs.fr )
1 – Identifier

4. Brief de design thinking
• Avec Quoi : Existant
• Le fichier des adhérents HelloAsso,
• Le site brickodeurs.fr
• Une appli web sur notre vps.
• Qui d’autres : Concurrences, autre solution ?
• Les autres associations locales ne semblent pas concerné par ce problème.
• CoderDojo ne propose pas, via son site, une telle approche.
• Nous ne pouvons pas nous permettre d’acquérir une solution professionnelle.
• Combien ? Budget, restriction.
• Nous souhaitons que l’application soit développé avec nos propres ressources
en interne avec une équipe de 5 personnes.
1 – Identifier

5. Brief de design thinking
• Quand ? Calendrier, Scénario d’utilisation.
• L’application sera utilisé majoritairement tous les samedis par les animateurs. Elle
sera accessible 24/7.
• Les animateurs alimentent les profils, les projets, les compétences (?)
• Les membres mettent à jour leurs compétences,
• Ces compétences pourraient être « prouvées » par la rédaction d’un wiki.
• Ces compétences pourraient être « récompensées » par des badges de compétences.
• Comment pouvons nous [Identifier] et [valoriser][les
compétences], [les projets], [les équipes] pour chaque
Brickodeurs pour permettre aux [animateurs] et aux [parents] de
voir leur progression.
1 – Identifier

6. Identifier les interactions
• À l’aide des cartes et des jetons du kit
Hackathon, essayons de voir et de
comprendre comment tout cela interagit.
1 – Identifier

7. Utilisation
Identifier la constellation d’acteurs
Droits
1 – Identifier
Cotisation
Budget
Compétences
Temps
Adhésion
AssociationParents
Membres
Animateurs
Ressources
Administration
€
Informations
Identifier les
flux entre
acteurs

8. Imaginer : Acteurs + Flux = Ressources ?2- Imaginer
Acteur Flux
• Nous allons imaginer pour chaque acteur associé à un flux de quelles
ressources il a besoin. Cela nous permettra d’en déduire des
fonctionnalités.
• Les Parents :
• + cotisations : flux financier alimente le budget de l’association
• + adhésion :
• + informations : ils sont informé des activités à venir du club par une
newsletter.
• Administration de l’association
• + Budget : gestion des ressources financières,
• + Compétences : gestion des ressources humaines,
• + Temps : gestion du Planning et horaire.
€
Droits
€

9. Imaginer : Acteurs + Flux = Ressources ?2- Imaginer
Acteur Flux
• Les animateurs :
• + temps : disponibilité du bénévole  planning
• + Compétences : qu’il va transmettre aux membres via des « médias » ou en séance,
• + avec l’utilisation : des ressources du club (local, machines, site web... )
• Le membre / Brickodeur
• + Informations : il est informé des activités à venir du club par une newsletter.
• + Expérience : au sein du club, il apprend via les « expériences » qu’il fait en étant
aidé par les animateurs et les autres membres  acquisition de compétences.
• + Projet : Les « expériences » se vivent au sein de projet : Construction de robot,
création de programmes…  acquisition de compétences.
• + utilisation des ressources du club (local, machines, site web... )  acquisition de
compétences.

10. Imaginer les fonctionnalités pour …
•Pour notre premier groupe d’acteurs :
• Les parents et l’administration de l’association :
• Adhésions, Flux financier et budget
• Déjà géré par HelloAsso
• Ne rentre pas dans notre problématique initiale
• Les informations sont déjà géré par le site web : articles et
newsletter.
• La gestion du planning
• Ne rentre pas dans notre problématique initiale
2- Imaginer
€
Droits

11. • Rappel de la problématique :
• Comment pouvons nous [Identifier] et [valoriser][les
compétences], [les projets], [les équipes] pour chaque
Brickodeurs pour permettre aux [animateurs] et aux [parents]
de voir leur progression.
• Pour notre deuxième groupe d’acteurs :
• Les animateurs :
• Compétences qu’il va transmettre aux membres via des « médias » ou en séance, avec
l’utilisation : des ressources du club (local, machines, site web... )
• Les Brickodeurs :
•  acquisition de compétences. Via expérience, projets et
ressources du club.
Imaginer les fonctionnalités pour …2- Imaginer

12. • La transmission et l’acquisition de compétences Via
expérience, projets et ressources du club.
•  Identifier une compétence ?
• C’est Quoi ? Aptitudes et personnalité + Expérience →
Compétences → Missions
• Qui ? Détenu par un membre
• Pourquoi : pour mettre en valeur ce qu’ils savent et partagent.
Donner envie aux autres de faire la même chose.
• Quand ? lorsqu’il l’a déclare, ou lorsqu’elle est identifiée par
un animateur. Lorsqu’il participe à un projet. Lorsqu’il rédige
un wiki dans une catégorie de compétences.
• Comment ? Avec un badge ?
• Où ? Sur le site des brickodeurs ?
Imaginer les fonctionnalités pour …2- Imaginer

13. Imaginer un modèle de données2- Imaginer
• Faire « rentrer » l’acteur dans la fonctionnalité.
• Acteur  rôle
• Ressources : site brickodeurs.fr
• Permet de rédiger des articles
• Description :
• Un [membre] rédige un [article] qui identifie une [compétence]
• Un [Badge] appartenant un domaine de [compétence] récompense un
[article]
• Un [badge] est remis dans le [Passeport] possédé par le [Membre]

14. 3 – Réali un cahier des charges
• Le modèle de données sera réalisé à partir de celui de Wordpress,
• Il faut ajouter les « types de post personnalisé » (TPP):
• Compétences,
• Badges.
• Il faut créer les pages suivantes pour visualiser les nouveaux TPP:
• Compétences : afficher leur description, qui les détient.
• Badges : conditions pour les obtenir, qui les détient.
• Il faut créer les contrôles suivants :
• Quand un membre rédige un (ou plusieurs) article(s) wiki dans une catégorie de
compétence.
• La qualité de l’article doit être validé par au moins 3 autres membres en « likant »
l’article.
• Si le membre a déjà rédigé plusieurs articles wiki et a déjà obtenu un (ou plusieurs)
badges de compétences alors il obtient un badge de niveau supérieur :
• Novice  débutant  confirmé  expert  Ninja
3 – Réaliser
Modèle
Les vues
Les
contrôleurs

15. 4- partager la solution
• Reste à faire :
• Prévoir un plan de communication pour inciter les membres à rédiger
des articles pour obtenir des badges.
• A suivre…
4 – Partager