Discussion :

[velocity]

Bonjour à tous,

J'ai pensé à mettre le lien vers mes comptes Git et SVN sur mon CV.
J'aimerai savoir votre avis. Si vous partagez mon avis, devrais-je:

1- Mettre un les liens Git et SVN seulement en haut du CV, ou
2- Mettre un lien spécifique sous chaque projet réalisé dans la rubrique expériences

Pourquoi SVN et Git ?
Puisque Git/GitHub ne permet d'avoir q'un seul répertoire privé alors que SVN/Bitbucket offre jusqu'à 5 répertoires privés (si je me trempe pas), j'ai pensé à réserver Git pour mes projets personnels et utiliser SVN pour mes projets de stages en entreprise.

Merci.

[BiM]

Bonjour,

Je pense que cela peut être une bonne idée de laisser accès à tes projets personnels mais attention, ils doivent avoir une qualité irréprochable, autant en terme de fonctionnement que de propreté du code, de commentaires, de documentation et de méthodes.

utiliser SVN pour mes projets de stages en entreprise.

Erreur !! Ce serait très mal vu surtout par tes anciennes entreprises qui pourrait juridiquement se retourner contre toi. Dans la théorie, on ne part pas de sa société avec le code en poche : il n'est pas public (à moins d'être open source) et ne t'appartient pas. Idem pour tes futurs employeurs qui pourrait croire que tu vas partir avec tout ou une partie du produit que tu auras à développer.
Dans la pratique, cela se fait beaucoup quand on est débutant de partir avec du code pour avoir quelques exemples concrets sous la main. Cependant, cela doit rester personnel.

[Invité]

Euh, si ce sont des projets réalisés en entreprise (que ce soit en stage ou en tant que salarié), les sources appartiennent aux entreprises, donc tu n'as pas le droit de les rendre publiques.
En mettant des liens vers les repositories sur ton CV, tu commets une faute et t'expose à des poursuites.

[velocity]

Ce serait très mal vu surtout par tes anciennes entreprises qui pourrait juridiquement se retourner contre toi

J'avais aussi un doute à propos du code en stage. Tempi, je n'aurai pas à me justifier devant le recrutement. Cependant, je me souviens d'un recruteur (en journée de recrutement par groupe) qui m'a demandé de lui envoyer mes travaux de stage pour vérifier le code. Je l'ai ignoré car l'idée d'envoyer mon code à une personne inconnu en pièce jointe ne m'a pas plu.

ils doivent avoir une qualité irréprochable

En ce qui concerne la propreté du code, j'aime écrire du code propre mais le problème est le manque de tests. Même si je connais JUnit je n'arrive toujours pas à effectuer la phase de Test ou du moins en TDD ou XP (à part les tests fonctionnels ce qui est chose naturelle), pensez vous que ça peut réduire l'utilité de mon code en CV?
Donc, Je ne garde que mes projets personnels et mes projets scolaires.

[Invité]

J'avais aussi un doute à propos du code en stage. Tempi, je n'aurai pas à me justifier devant le recrutement. Cependant, je me souviens d'un recruteur (en journée de recrutement par groupe) qui m'a demandé de lui envoyer mes travaux de stage pour vérifier le code. Je l'ai ignoré car l'idée d'envoyer mon code à une personne inconnu en pièce jointe ne m'a pas plu.

C'était peut-être un test juste pour savoir si tu allais leur donner ou pas.

[GuillaumeJ]

En dehors du fait que ton code en entreprise ne t'appartient pas, et que tu peux pas le sortir du boulot, même sur un repository privé...

Je pense que c'est une bonne idée, d'une portée limitée pour 50% des recrutements :entre les RH qui te sélectionneront pas avant même de faire passer ton cv a un technique capable de comprendre ton code, les recrutements sans .. critères techniques réels (SSII)..

Sur l'idée de "qualité irréprochable", je pense que c'est assez utopique : entre le fait que personne n'est parfait et que personne n'a les mêmes normes... Je pense qu'il faut juste s'en tenir a du bons sens :
- un projet qui compile et se lance
- une organisation correcte : découpage projets, classes
- une nomenclature propre : éviter d’appeler des fonctions, fichiers, variables toto ou truc, éviter le mauvais anglais ou français, ou trop de mélange des deux
- mettre des tests, même si t'as pas 100% de coverage
Pour la doc... J'ai tendance a me dire que le README de GitHub, dans ce cas précis de "Je m'expose pour me vendre", ça doit être un argument commercial, et donc a le concevoir comme une vitrine "Dans ce projet, j'ai fait du MVVM" etc..

Au final, je me dis que tout examen du code ne sera que partiel : le gars va juste voir ce qui est apparent, y a peu de chances qu'ils inspectent chaque ligne..

[Cirrus Minor]

Euh, si ce sont des projets réalisés en entreprise (que ce soit en stage ou en tant que salarié), les sources appartiennent aux entreprises, donc tu n'as pas le droit de les rendre publiques.

Est-ce également le cas pour les stages qui ne sont pas rémunérés ?
(Juste par curiosité)

[Invité]

Est-ce également le cas pour les stages qui ne sont pas rémunérés ?
(Juste par curiosité)

Oui.

[GuillaumeJ]

Oui.

J'imagine que pour un stage (voir même un emploi salarié, mais plus délicat de le faire dans le but d'enrichir son CV pour se barrer ) tu peux aussi demander la permission.

[Invité]

J'imagine que pour un stage (voir même un emploi salarié, mais plus délicat de le faire dans le but d'enrichir son CV pour se barrer ) tu peux aussi demander la permission.

C'est illégal puisque ce que tu produis dans le cadre de ton travail / stage appartient à la société...
Mais dans les faits, on est tous parti avec du code, surtout en début de carrière.

[BiM]

C'est illégal puisque ce que tu produis dans le cadre de ton travail / stage appartient à la société...
Mais dans les faits, on est tous parti avec du code, surtout en début de carrière.

C'est un peu ce que je disais en début de sujet.

Le code ne t'appartient même si tu n'as pas été payé car l'entreprise a mis à disposition des outils (matériels et logiciels), ainsi qu'un encadrement pour que tu puisses faire les réalisations demandées dans de bonnes conditions.

[Cirrus Minor]

Es-tu bien sûr de toi, 7gyY9w1ZY6ySRgPeaefZ ?

D'après ce ticket de blog, que j'ai trouvé avec une brève recherche, ce n'est pas si évident que ça:
http://www.blog-lamon-associes.com/l...-appartient-il

Dans ce cas, il faut appliquer un grand principe de droit : les exceptions aux principes s’interprètent strictement. Le principe = celui qui crée une œuvre protégée par le droit d’auteur est titulaire des droits. L’exception : le logiciel développé par un salarié « appartient » à son employeur. Corollaire : celui qui n’est pas salarié n’est pas concerné par l’exception.

Mais je ne sais pas ce que ça vaut...
J'avais essayé de me renseigner quand j'étais en stage (il y a une dizaine d'années, je n'étais pas payé) mais je n'avais rien trouvé de concluant.

[GuillaumeJ]

C'est illégal puisque ce que tu produis dans le cadre de ton travail / stage appartient à la société...
Mais dans les faits, on est tous parti avec du code, surtout en début de carrière.

C'est illégal .. si tu n'as pas la permission, et on peut imaginer des cas ou cela parait envisageable.

Imagine que par exemple, dans le cadre de ton travail sur un logiciel de gestion, tu fasse un petit outil pour par exemple, gérer les déploiements de ce logiciel sur des VMs. Autrement dit, pas du code métier de l'entreprise. :c cet outil pourrait être open-sourcé.
Il me semble aovir déja vu des porjets open source (certes pas français) tiré de ce genre de projet annexe a ton travail quotidien.

Au final, pour revenir ce que je disais sur la qualité du code, je me dis qu'il faut mieux un repository avec du code correct, que pas de repository du tout. En sachant bien que dans beaucoup de recrutements, ca comptera pas.

[phili_b]

Entre se faire une boite-à-outils perso et non public (un bloc-notes en fait), et publier un projet d'entreprise sur un SVN public il y a un monde.

A moins que ça soit de l'open source, ça ne me plairait pas du tout si j'étais une entreprise de voir mes projets sur un SVN.

Et même si c'était légal (autorisation de l'entreprise, open source, source appartenant au développeur) c'est à double tranchant de fournir des sources pour juger de la pertinence d'un CV. Ça peut par exemple donner un prétexte à l'éventuel employeur de porter un jugement négatif, avant même l'entretien.

[velocity]

Je partage votre avis, en tant que directeur, je ne voudrai pas que les projets réalisé au sein de mon entreprise soient mis en libre accès sur web à condition que ce soit un projet en open source, dans la limite il faudrait avoir l'accord du chef de projets.
Je dis oui pour les projets personnels sur le CV et non pour les projets en entreprise même si c'était en stage.

[GuillaumeJ]

c'est à double tranchant de fournir des sources pour juger de la pertinence d'un CV. Ça peut par exemple donner un prétexte à l'éventuel employeur de porter un jugement négatif, avant même l'entretien.

C'est tout aussi plausible que de dire que ca peut aider a donner un jugement positif avant l'entretien...

Ce que tu es train de dire aussi, c'est que tes sources peuvent prouver que ton CV est bidon, non ?

[Zirak]

En même temps, cela me parait tellement complexe de déterminer à partir de quel moment, c'est de la divulgation de code interne ou non pour une entreprise...

Je veux dire qu'à moins de recoller le projet 100% à l'identique, ou que la société avait un besoin tellement unique que c'est facile de déterminé qu'il s'agit bien du code développé à sa demande ou non, sinon cela me parait quand même légèrement difficile.


Qu'est-ce qui empèche un dev, de reprendre un developpement effectué dans sa société par ses soins, de l'améliorer, et de le présenter ? Après tout, ce n'est pas une copie conforme du code présent dans la société ? Le code est déjà sorti une fois de sa tête, même sans avoir embarqué le code à proprement parlé, il est potentiellement capable de le ressortir (bon pas à la virgule près, c'est sûr) non ?

Typiquement quelqu'un qui developpe une API pour effectuer une tâche X pour sa société. S'il reprend cette API, l'améliore avec des nouvelles fonctions (ex : plus de format prise en compte, des traitements supplémentaires, etc) , s'il met à dispo le code de cette nouvelle API, peut-il être inquiété par son ancienne entreprise ?

[Invité]

Typiquement quelqu'un qui developpe une API pour effectuer une tâche X pour sa société. S'il reprend cette API, l'améliore avec des nouvelles fonctions (ex : plus de format prise en compte, des traitements supplémentaires, etc) , s'il met à dispo le code de cette nouvelle API, peut-il être inquiété par son ancienne entreprise ?

Avant de parler de mettre à dispo ce que tu décris, rien que reprendre une API de ta boîte pour en faire des trucs pour toi (même si c'est pour rien en faire), est interdit.
En fait le code est même pas censé sortir de la boîte sans autorisation.

[Invité]

En même temps, cela me parait tellement complexe de déterminer à partir de quel moment, c'est de la divulgation de code interne ou non pour une entreprise...
Je veux dire qu'à moins de recoller le projet 100% à l'identique, ou que la société avait un besoin tellement unique que c'est facile de déterminé qu'il s'agit bien du code développé à sa demande ou non, sinon cela me parait quand même légèrement difficile.

Je connais un cas où le type s'est fait condamné car il a été retrouvé du code identique dans le site web de son nouvel employeur.
D'un autre côté, amener et brancher son disque externe perso la veille de son départ, devant tout le monde, ça fait preuve d'un certain manque de jugement du type en question...

[Njörd]

Bonjour,

Qu'est-ce qui empêche un dev, de reprendre un développement effectué dans sa société par ses soins, de l'améliorer, et de le présenter ? Après tout, ce n'est pas une copie conforme du code présent dans la société ? Le code est déjà sorti une fois de sa tête, même sans avoir embarqué le code à proprement parlé, il est potentiellement capable de le ressortir (bon pas à la virgule près, c'est sûr) non ?

Tu poses le doigts sur le nœud du problème. En France et en Europe, les développeurs ne sont pas propriétaire de leurs œuvres. Par contre, ils sont propriétaire de leur savoir-faire. Autrement dit, la somme des compétences et connaissances qui leurs ont permis de faire l'application. Un développeur peut donc réécrire une application faite en entreprise. il s'agit, du point de vue du droit, d'une nouvelle œuvre de l'esprit puisqu'il y a réécriture. Maintenant, la réécriture doit être complète pour éviter tout problème d’interprétation juridique.

Si tu réécris tout, tu améliores (ou pas) et donc tu crées quelque chose de nouveau Il s'agira des mêmes fonctionnalités mais elles seront différentes dans leur utilisation. Il en va de même pour la notion d'idée. On ne peut pas breveter une idée, par contre on peut breveter la façon dont on a mis en œuvre cette idée.