Pour rappel : Bien que la collaboration avec d’autres apprenant soit recommandée, l’évaluation des livrables de vos projets reste individuelle.
En cela, vous devez fournir un travail personnel et unique.
Contrairement aux idées reçues, le métier de développeur est bien plus collaboratif que ce que l’on ne pense. Être développeur au sein d’une structure (entreprise, association, etc) c’est occuper une fonction pivot autour de laquelle les équipes métiers gravitent et s’organisent. Mais être développeur, c’est aussi travailler avec d'autres développeurs.
En cela, OpenClassrooms encourage dès la formation, la collaboration et l’entraide entre les apprenants des parcours de formation de code (Développeur Web, Développeur d’application JavaScript - React, iOS, Android etc.). Cela soulève immédiatement les règles à respecter pour éviter toute forme de plagiat de code, l’invalidation des livrables lors de soutenance et à terme le refus du jury.
Comment collaborer avec d’autres apprenants au cours de ma formation OpenClassrooms ?
Vous pouvez collaborer de différentes manières avec d’autres apprenants au cours de votre formation OpenClassrooms. Vous pouvez :
- organiser des sessions de travail en visioconférence avec d’autres apprenants
- recommander et partager des ressources
- discuter sur la méthodologie à utiliser
- partager des astuces pour avancer plus rapidement
- etc.
| À faire (car c’est de la collaboration) ✅ | À ne pas faire (car c’est de la triche) ❌ | |
| Partager votre écran avec d’autres apprenants dans le but de discuter de votre code lors d’une réunion et pour expliquer votre solution. | Envoyer votre code à un autre apprenant et lui suggérer de le copier sans explication et sans en connaître l’utilité du destinataire. | |
| Partager votre repository avec un apprenant en posant des questions sur des parties spécifiques qui vous posent problème. | Partager votre code publiquement sur un groupe Slack pour demander de l’aide. | |
| Collaborer avec des apprenant qui travaillent sur le même projet que vous. | Demander des solutions “ toutes faites “ à des apprenants ayant déjà terminé le projet sur lequel vous étudiez. | |
| Aider un apprenant à comprendre un concept sur lequel il ou elle a du mal à avancer. | Donner un code fonctionnel à un apprenant sans chercher à ce qu’il le comprenne. | |
| Consulter le code de quelqu'un d'autre en vous assurant de le comprendre entièrement avant de vous en inspirer pour vos besoins. | Copier/Coller un code sans le comprendre (et sans être capable de l’expliquer à votre mentor ou pendant votre soutenance). | |
| Prendre en considération les commentaires des autres apprenants, même sur un morceau de code qui fonctionne - il existe toujours plusieurs bonnes réponses. |
|
Il est important de spécifier que chez OpenClassrooms l’évaluation de vos projets reste individuelle et vos livrables doivent être personnels et différents de ceux de vos collègues !
Par ailleurs, nous vous rappelons comme le décrit cet article que :
- Vos connaissances seront évaluées et vérifiées par un mentor évaluateur lors de votre soutenance. Vous devrez partager votre cheminement de pensée. Tout soupçon de fraude, de plagiat ou de triche sera signalé et des mesures seront prises.
- En recopiant le travail d’autrui, vous encourez la sanction définitive qu’est l’exclusion et donc la fin anticipée de votre formation.
- Il n'est vraiment pas dans votre intérêt, ni dans celui de la communauté toute entière, de reproduire le code ou le travail d'un.e autre. Dans votre futur emploi, vous devrez prouver que vous maîtrisez ces compétences.
Disponibilité de votre repository
Nous vous recommandons de garder vos repository en mode public afin que votre évaluateur ainsi que le jury puissent y accéder pour les évaluer en temps voulu.