L'obsolescence programmee au travail

Le problème des entreprises c'est que souvent elles utilisent des outils sans savoir réellement ce qu'il y a derrière.

Et c'est tout aussi valable pour un logiciel développé en interne que pour une machine outil achetée à une entreprise spécialisée dans leur construction.

Mais dans le monde de l'entreprise il y a une notion que nous n'utilisons pas trop en tant que particulier, c'est le retour sur investissement.

Si un produit, soft ou hard, est rentabilisé en 5 ans, quand bien même sa conception le lie à son développeur, si celui-ci n'est plus disponible une fois le retour sur investissement atteint, tant pis on investie dans une nouveau développement.

De fait, les gens indispensables, il y en a plein les cimetières.

Même chez EDF cité en exemple ...

Le savoir qui se perd n'est pas le fait d'employés qui font de la rétention d'information la plupart du temps.

On externalise la maintenance de plus en plus par exemple.

L'entreprise passe un contrat pour 5 ans avec un prestataire qui lui loue des personnels et des moyens pour assurer la maintenance.

Les gens apprennent sur le tas comment fonctionne l'usine, capitalise sur l'expérience du quotidien.

AU bout de 5 ans, le service achat passe le contrat à une autre entreprise moins chère.

Et tout le savoir disparait.

A charge du nouveau prestataire de tout redécouvrir ...

Même chose avec la gestion du personnel.

Ca coute cher le personnel.

C'est toujours présenté comme une charge pour l'entreprise plutôt que comme une force.

On réduit donc le nombre.

On ne met plus un jeune avec un ancien pour que le savoir se transmette.

Résultat, à chaque départ en retraite le savoir disparait ...

Et malheureusement, tout ce savoir ne peut pas être couché sur le papier.

En tout cas je ne connais pas de boite qui le fasse.

Ca demande des moyens trop importants.

Déjà je ne vois pas comment écrire des scripts en C++

Avoir une application C# par exemple et y inclure des portions en C++.

Ensuite les programmeurs proofessionnels qui bossent avec moi sont tout à fait compétents en C# , C++ et JScrispt au minimum.

Je connais beaucoup de developer .NET et aucun d'entre eux ne connaissent C++. J'imagine que tes informaticiens sont plutot d'un certain age et sont plutot bien payee par rapport a la moyenne des developers (ici, la plupart n'ont meme pas de licences d'informatique). Au RU, les developeurs C++ se trouvent surtout dans les banques ou ils gagnent effectivement beaucoup plus que la moyenne.

Mais globalement, je considère que c'est au patron de l'entreprise (prestataire ou client) de ne pas se mettre en position de dépendre d'une seule personne.

Oui. Plus facile a dire qu'a faire, cependant. Tu peux m'embaucher avec un certain bagage (C#, VB, C++) mais si je trouve un language qui me permet d'optimiser l'application (comme par exemple R ou Python pour les algo de data mining), je vais l'introduire sans necessairement te demander la permission. Tu ne l'apprendra que lorsque je serais parti ou lorsque je demanderais une augmentation ("sinon je me barre").

@Dinosaure, malheureusement ca rrive que les entreprises prennent ce risque, mais c'est leur stratégie et il le font en connaissance des risques...

là actuellement je bosse sur un projet assez sensible de par son domaine et on est 3 prestataires à bosser dessus, si on part ils sont dnas la merde (déjà que nous on galère à cause de la complexité de l'application... :D )

Et c'est ce qui fait que l'entreprise va reflechir a deux fois avant de refuser votre prochaine augmentation..

Avoir une application C# par exemple et y inclure des portions en C++.

Ce n'est pas un script alors

Un script s'exécute sans compilation ce qui n'est pas le cas des langage de la famille du C

Je connais beaucoup de developer .NET et aucun d'entre eux ne connaissent C++. J'imagine que tes informaticiens sont plutot d'un certain age et sont plutot bien payee par rapport a la moyenne des developers (ici, la plupart n'ont meme pas de licences d'informatique). Au RU, les developeurs C++ se trouvent surtout dans les banques ou ils gagnent effectivement beaucoup plus que la moyenne.

C'est quoi ton "RU" ?

Dans les banques (côté gros système bancaires) il y'a surtout du COBOL et du Java...

Oui. Plus facile a dire qu'a faire, cependant. Tu peux m'embaucher avec un certain bagage (C#, VB, C++) mais si je trouve un language qui me permet d'optimiser l'application (comme par exemple R ou Python pour les algo de data mining), je vais l'introduire sans necessairement te demander la permission. Tu ne l'apprendra que lorsque je serais parti ou lorsque je demanderais une augmentation ("sinon je me barre").

ben si tu bosses ainsi tu es un mauvais développeur c'est tout, développer ce n'est pas juste pisser du code

Et c'est ce qui fait que l'entreprise va reflechir a deux fois avant de refuser votre prochaine augmentation..

Je vois pas en quoi, ca n'a aucun sens ce que tu dis. C'est de la faute de l'entreprise si on est dans une telle situation pas de la notre qui subissons ces choix... on fait du mieux qu'on peut pour que les développeurs qui nous succèderont se prendront le moins possible la tête mais faudrait refaire à propre toute l'appli et ca ce n'est pas possible...

Mais dans le monde de l'entreprise il y a une notion que nous n'utilisons pas trop en tant que particulier, c'est le retour sur investissement.

Si un produit, soft ou hard, est rentabilisé en 5 ans, quand bien même sa conception le lie à son développeur, si celui-ci n'est plus disponible une fois le retour sur investissement atteint, tant pis on investie dans une nouveau développement.

C'est la ou le probleme reside. Pour un employee qui desire progresser rapidement dans sa carriere, etre bloquee avec la meme technologie pendant 5 ans, ca commence a etre long.

Je connais beaucoup de developer .NET et aucun d'entre eux ne connaissent C++. J'imagine que tes informaticiens sont plutot d'un certain age et sont plutot bien payee par rapport a la moyenne des developers (ici, la plupart n'ont meme pas de licences d'informatique).

C'est absolument le contraire.

Ce sont des jeunes qui sortent d'école d'ingé informatique. Évidemment il faut les payer un chouïa plus que le type que tu recrutes au hasard.

C'est absolument le contraire.

Ce sont des jeunes qui sortent d'école d'ingé informatique. Évidemment il faut les payer un chouïa plus que le type que tu recrutes au hasard.

On a pas de Grandes-ecoles ici, d'ou mon apriori. Ici, la plupart des informaticiens ont au plus une licence.

Sauf qu'il est rare quand un client est capable de connaitre avec precision les techniques et languages utilisees pour creer certaines applications. Dans le domaine du developement WEB par exemple, on peut ecrire certaines parties en MVC, d'autres en ruby, python, etc. Dans les domaines des applications, un developeur .Net peut introduire des scripts en Python, en C++ etc.. sachant que ces competences se retrouvent rarement dans une seule personne.

Tout dépend du besoin, mais pour faire du web tu peux en effet te tourner vers du .net, du java, ou tout simplement du PHP, ou du Node JS ...

Ces choix ne sont justement pas idiot car ce sont des technologies répandues, et tu pourras retrouver des personnes compétentes ou des prestataires. Pour le python, par exemple, c'est plus délicat : moins répandu, moins de chances de trouver un panel suffisant de gens formés.

Bref, tu peux recruter quelqu'un de bonne foi qui maîtrise bien une techno fiable et qui fera le boulot. Mais c'est à toi de vérifier aussi si la techno utilisée est assez courante pour éventuellement passer par d'autres prestataires. Et voir également si sa durée de vie est suffisante, et si il y a des possibilité d'évolutivité (vers des fonctionnalités futures). Bref, comme dans tout investissement, il faut réfléchir à ce que l'on veut et à son besoin.

(maintenant, il est vrai que dans l'informatique nombre de clients exigent surtout un résultat - souvent assez flou, à commencer pour eux même - sans se pencher sérieusement et étudier leur besoin).

C'est se rendre indispensable vis a vis des clients. Ces clients deviennent dependant d'un employee en particulier plutot que de l'entreprise en elle meme.

C'est souvent le cas, de toute façon. On se retrouve "indispensable" dès lors que l'on assure un projet de manière autonome.

Il y a toujours possibilité de remplacer le prestataire, mais celui-ci sera toujours plus apte à comprendre, modifier ses sources (enfin bon, tout dépend du type de projet également).

Et là aussi ça dépendra des demandes du client, des documents d'étude qu'il a demandé, etc ...

Des gens indispensables, il y en a plein le cimetière. Se rendre utile est grandement suffisant.