Discussion :

[JPLAROCHE]

en faite ce n'ai pas tant l'importance de savoir si on est capable d'intégré plusieurs compétence ( en 40 ans d'expérience) je suis architecte de BD un vrais programmeur (dans son ancien sens j'aime encore prendre mes bottes et me noyer dans le code) un chef de projet, un concepteur , bon je m'arrête là pas envie de m’étaler. juste que je voulais rapporter mon expérience.
effectivement les entreprises en vienne a ce dire pourquoi prendre du personnel puisque l'on a un homme orchestre!
pourquoi faire toutes les analyse sur papier puisque vous maîtrisez le sujet (MAIS on a plus temps OUI le temps ce raccourcie car on a toujours 2 mains et les heures on ne les compte plus on dort sur place )
que pour l'entreprise cela devient pernicieux car si la personne part OUPS msieu y a plus personne et après cela coûte chère mais çà on veux pas le voir.

le seul intérêt et cela ma bien été fait comprendre par un grand chef d'entreprise au Québec (pendant mes vacances) il est uniquement qu'il va pouvoir suivre les différentes branche et faire leurs raccords suivre son équipe et apporter son expérience pour faire évoluer et susurrement évité des Écueils . bref quand il est possible d'avoir plusieurs cordes a son arc (mais pas en 5 minutes ni en 5 ans ) mais en aucun cas ne remplace une équipe .

la fin de mon histoire 3 burn aout une entreprise qui devait sortir du rouge réussi (450 personnes) mais j'ai payé la facture et dut finir .... aujourd'hui retraite forcée enfin de compte je traille en consultant en attendant quelle chg de system pour cette boite mais quel bêtise ..... car on a fini de virer toutes l'équipe pour gagné de l'argent !!!! j'ai encore mal... et prendre 2 mecs au smigue oui vous lisez bien au smigue . jamais j'aurais cru voir cela. alors bien-sur faut pas trop leurs en demander.

[Alexandre T]

Bonjour,

Le sujet entre polyvalence et monovalence a toujours été une discussion de café dans les bureaux RH. Des développeurs full stack, je ne sais pas si cela existe. Mais un développeur se présentant comme un cador aurait peu de chance d'intégrer notre équipe qu'il soit polyvalent ou monovalent. J'apprécie les développeurs avec une grande culture générale (et pas forcément informatique). Je préfère m'entourer d'équipiers qui connaissent leurs limites et qui savent vers quel collègue se tourner en cas de doute. Cela demande de se connaître soi-même, de s'intéresser à ses collègues. Mince, je préfère les qualités humaines aux notes de concours et aux diplômes.

[dissert]

Tu pousses le concept de FullStack un peu loin là :p

Pas tellement. Il y a deux sortes d'indépendants : ceux qui se contentent de se faire porter par des intermédiaires, et ceux qui, effectivement, cumulent, à leur niveau, toutes les casquettes d'une société classique.

Une bonne partie des indépendants avec lesquels je gravite (et je suis dans le lot) sont dans le second cas. Il est vrai qu'il y a peu de débutants dans le lots (compter au moins 7 à 15 ans minimum d'expérience).

[philippeblanc]

Je suis assez d'accord avec certains commentaires sur le fait qu'un développeur full stack n'existe pas vraiment, mais une longue expérience professionnelle permet toutefois d'avoir une assez large vision des choses pour être capable de gérer / réaliser un projet dans sa globalité. Je pense que c'est le cas de pas mal de freelance, dont je fais parti.
Les parcours professionnels sont parfois variés et l'expérience s'en trouve enrichie.
Un indépendant qui gère seul un projet de bout en bout n'obtiendra sans doute pas le résultat d'une équipe complète multidisciplinaire, et en tout cas pas dans le même laps de temps, mais aura tout de même réussi seul. Alors certes on ne pourra pas dire de lui qu'il est "expert" dans toutes les disciplines qu'il aborde, mais il pourra peut être prétendre l'être dans certaines et moins dans d'autres.

Le développeur full stack n'existe pas, mais des indépendants qui gèrent seul des projets complets existent quand même !

[tralloc]

Je pense que tout dépend :
- de la taille de l'entreprise
- de la taille des projets
- des gens qui développent.

Je trouve personnellement qu'il est agréable de concevoir sa base de données, d'écrire les moulinettes qui organisent des transferts de données, de créer ses tables ensuite de passer sur la persistence, les objets métiers, puis de toucher à la partie affichage.
On peut dire que je suis un peu full stack, peut-être pas à 100% mais au moins à 90.
Je pense que si je ne touchais pas à tout je finirais par m'ennuyer et de tomber dans une routine triste et affligeante, en travaillant comme ça on fait toujours marcher son cerveau car on doit se renouveler encore et toujours sur toutes les techniques, c'est donc plus intéressant. Il y a toujours des défis techniques.

Ce qui ne veut pas dire que je ne travaille ni seul ni en équipe. On bosse bien, chacun s'occupe d'une partie du projet. Et lorsqu'il y a un problème, on peut se conseiller, se compléter. Revoir ensemble certaines parties (ex interfaces graphiques, car c'est pas mon fort ...).

Dans une petite structure ça passe. Je ne pense pas que ça économise quoi que ce soit en main d'œuvre, mais ça permet au développeur d'être heureux et donc de bien travailler.

Ce qui est plus difficile moralement c'est de développer quelque chose seul et sans aucune aide, sans interaction avec d'autres. Mais c'est pas irréalisable.

[Paul TOTH]

Bonjour,

Le sujet entre polyvalence et monovalence a toujours été une discussion de café dans les bureaux RH. Des développeurs full stack, je ne sais pas si cela existe. Mais un développeur se présentant comme un cador aurait peu de chance d'intégrer notre équipe qu'il soit polyvalent ou monovalent. J'apprécie les développeurs avec une grande culture générale (et pas forcément informatique). Je préfère m'entourer d'équipiers qui connaissent leurs limites et qui savent vers quel collègue se tourner en cas de doute. Cela demande de se connaître soi-même, de s'intéresser à ses collègues. Mince, je préfère les qualités humaines aux notes de concours et aux diplômes.

attention, polyvalent ne veux pas dire omniscient. même avec une champ de compétence large, il faut connaitre ses limites, savoir quels projets sont trop vastes pour tenir dans les mains d'un seul développeur par exemple, ou quels champs de compétence nous échappent. Par exemple je ne suis pas graphiste, j'ai beau faire des icônes sympas ou des sites web efficients, ils sont visuellement médiocres par rapport au travail d'un graphiste doué En programmation je ne prendrais jamais un projet dotNet ou JEE, car je ne suis pas compétent dans ces domaines et ne cherche pas à le devenir d'ailleurs. Mais je pose toujours la question autrement, voulez-vous une solution dotNet ou une solution qui fonctionne et pour laquelle j'ai le choix des armes ? La réponse peu être une solution dotNet qui fonctionne, mais dans ce cas je décline car ce n'est pas mon champ de compétence.

[T`lash]

Après tout dépend de la taille du projet...

Je suis ce développeur puisque je suis le seul codeur pour un groupement de sociétés qui totalisent une centaine d'employés.
Il y a 3 autres informaticiens, mais dans d'autres domaines (SysAdmin, postes clients, ...).
Pour développer les outils internes je dois donc tout faire de A à Z, ce qui comprend souvent le cahier des charges (on me dit "on a besoin de ça pour faire ceci" et il faut que j'arrive à décrypter les besoins du services en question).
Il me faut manier PHP, Javascript, Java, Python, BASH, Photoshop, etc.
Et jusque là je m'en sors plutôt bien, parce qu'on ne s'ennuie pas. Par contre cela nécessite une gymnastique cérébrale assez fatigante, donc je le fais à 30 ans, mais je ne me vois pas travailler dans ces conditions avec 20 ans de plus. C'est d'ailleurs pour cela que j'ai été embauché : je remplace à ce poste un collègue qui a dépassé la cinquantaine et qui n'a plus l'énergie (ni l'envie) de faire le grand écart en permanence et de se mettre à jour dans toutes les technologies impliquées. Il s'est donc spécialisé dans un domaine plus pépère pour finir sa carrière.

[MichaelREMY]

Après tout dépend de la taille du projet...

Je suis ce développeur puisque je suis le seul codeur pour un groupement de sociétés qui totalisent une centaine d'employés.
Il y a 3 autres informaticiens, mais dans d'autres domaines (SysAdmin, postes clients, ...).
Pour développer les outils internes je dois donc tout faire de A à Z, ce qui comprend souvent le cahier des charges (on me dit "on a besoin de ça pour faire ceci" et il faut que j'arrive à décrypter les besoins du services en question).
Il me faut manier PHP, Javascript, Java, Python, BASH, Photoshop, etc.
Et jusque là je m'en sors plutôt bien, parce qu'on ne s'ennuie pas. Par contre cela nécessite une gymnastique cérébrale assez fatigante, donc je le fais à 30 ans, mais je ne me vois pas travailler dans ces conditions avec 20 ans de plus. C'est d'ailleurs pour cela que j'ai été embauché : je remplace à ce poste un collègue qui a dépassé la cinquantaine et qui n'a plus l'énergie (ni l'envie) de faire le grand écart en permanence et de se mettre à jour dans toutes les technologies impliquées. Il s'est donc spécialisé dans un domaine plus pépère pour finir sa carrière.

Dans votre cas, ne manque-t-il pas un DSI ou chef de projet IT (un chef d'orchestre en bref) dans votre structure de 100 personnes ? c'est étrange non ?

[Cyrano]

Dans votre cas, ne manque-t-il pas un DSI ou chef de projet IT (un chef d'orchestre en bref) dans votre structure de 100 personnes ? c'est étrange non ?

Je prends la liberté de répondre avant T`lash sur ce point, me trouvant dans une situation similaire. Et la réponse est non, pas obligatoirement. D'abord parce que l'activité de l'entreprise n'est pas obligatoirement l'informatique et que le réseau interne lui-même ne comporte pas forcément une machine pour chaque employé. Ça peut se limiter à quelques machine pour quelques administratifs, le reste du personnel ayant une activité sans lien avec les ordinateurs. Un DSI dans ce contexte serait éventuellement incongru.

Pour ma part, j'ai construit un ERP pour un groupe d'entreprises comportant 4 sociétés distinctes, chacune ayant un type d'activité lui étant propre et sans nécessairement de lien avec l'activité des autres. Au total, ça peut représenter pas mal de monde, mais au niveau administratif, ça représente moins de 10 personnes, un DSI là-dedans serait un tantinet exagéré. Il faut donc remplir soi-même le rôle de chef d'orchestre.

[Heirem]

J'aime cet article qui dit "Ca ne marche pas quand il y a plusieurs personnes parce qu'elles ne veulent pas communiquer, mais une personne qui sait tout faire ça ne marche pas non plus"
Avec comme seul argument : "il faut pousser à la communication, et revenir à des équipes de plusieurs personnes... Sachant que j'ai dit plus haut que ça ne marchait pas parce que des fois ils ne veulent pas communiquer et que ça pousse à l'échec..."

Bref, j'aime ces articles qui aiment à faire des généralités de cas particuliers. J'ai connu des dev en équipe multicompétence qui se sont super bien passées, j'ai connu des dev en équipes fullstack (où tout le monde était full stack, mais chacun sur sa partie, avec un lead dev senior qui pilotait la qualité) et ça s'est bien passé, et j'ai connu aussi l'inverse dans les mêmes situation.
Ce qui changeait? Les personnes...

L'important, c'est pas de savoir si on bosse en équipe ou si on bosse tout seul, l'important c'est de mettre en équipe des gens qui peuvent et savent travailler en équipe.

Ha merde alors, je suis en train de dire que pour réussir, il faut qu'on s'occupe des gens et qu'on sache s'adapter à son environnement !

Je n'aurais pas dis mieux !
Et comme l'a fait si justement remarqué Népomucène, de quelle envergure de projets parle-t-on ?
Je rajouterais aussi une autre critère d'appréciation : de quelle nature de projet il s'agit ?
Car nous avons beau être des techniciens de la chose informatique et du développement en particulier, nous sommes aussi concernés par l'objet d'un projet, et ses règles métiers éventuelles.
Et même un administrateur système peut y être confronté dans certains cas !

Un peu fatigué de ces déclarations à l'emporte pièce et de ces visions en noir et blanc

[alexvb6]

Ce qui fait un bon développement, c'est le choix des individus.
Pourquoi se retrouve-t'on aujourd'hui à "un seul individu gère tout" ?
La réponse se trouve dans le portefeuille : plus rien ne vaut rien, tout est gratuit, rapide, pas cher.
Un développeur ne doit rien coûter non plus. Et il doit être aussi performant qu'une équipe (mais qu'on ne paierait jamais, car ils sont trop nombreux).
Les sites internet doivent être gratuits. Sans publicité.

Au final, des développeurs full-stack j'en connais, mais le problème est plus global : le système capitalistique tend vers le rien, et détruit la valeur de tout ce qu'il touche.
Le temps, l'argent, le travail, la réflexion, l'effort, le service-rendu, la conception, la réalisation : Rien ne vaut rien. Alors quand une boite veut "vraiment" développer un projet, elle se "résoud" à payer 1 MEC, et c'est déjà le bout du monde... Tu m'étonnes que le full-stack a quelques beaux jours devant lui...avant de crever lui aussi. Dommage, tout ça était pourtant bien parti à y regarder qques dizaines d'années en arrière.

[ChristianRoberge]

Une seule personne qui connait tout n'est pas une chimère. J'ai rencontré quelques rares personnes qui sont à ce niveau mais elles sont limités car elle n'ont pas le temps de tout faire et de large connaissance en tout implique forcément des connaissances pointues relativement faibles comparées à des experts qui n'ont qu'une spécialité à suivre. Donc, l'industrie aimerait bien avoir une seule personne pour l'ensemble d'un projet, mais cela est une chimère.

[MichaelREMY]

Ce qui fait un bon développement, c'est le choix des individus.
Pourquoi se retrouve-t'on aujourd'hui à "un seul individu gère tout" ?
La réponse se trouve dans le portefeuille : plus rien ne vaut rien, tout est gratuit, rapide, pas cher.(...)

je ne suis pas d'accord, un bon individu ou un mauvais n'engage pas la réussite ni l'échec d'un projet de développement. Il faut arrêter de tout faire dépendre du "pauvre" développeur.
Ce qui prime c'est la méthode de gestion du projet et s'y tenir strictement et rigoureusement.

[Cyrano]

je ne suis pas d'accord, un bon individu ou un mauvais n'engage pas la réussite ni l'échec d'un projet de développement. Il faut arrêter de tout faire dépendre du "pauvre" développeur.
Ce qui prime c'est la méthode de gestion du projet et s'y tenir strictement et rigoureusement.

Vrai à condition que ce ne soit pas le développeur lui-même qui ait en charge également la gestion dudit projet.

[T`lash]

Je prends la liberté de répondre avant T`lash sur ce point, me trouvant dans une situation similaire. Et la réponse est non, pas obligatoirement. D'abord parce que l'activité de l'entreprise n'est pas obligatoirement l'informatique et que le réseau interne lui-même ne comporte pas forcément une machine pour chaque employé. Ça peut se limiter à quelques machine pour quelques administratifs, le reste du personnel ayant une activité sans lien avec les ordinateurs. Un DSI dans ce contexte serait éventuellement incongru.

Pour ma part, j'ai construit un ERP pour un groupe d'entreprises comportant 4 sociétés distinctes, chacune ayant un type d'activité lui étant propre et sans nécessairement de lien avec l'activité des autres. Au total, ça peut représenter pas mal de monde, mais au niveau administratif, ça représente moins de 10 personnes, un DSI là-dedans serait un tantinet exagéré. Il faut donc remplir soi-même le rôle de chef d'orchestre.

C'est tout à fait ça : je travaille pour un groupe d'une douzaine d'entreprises travaillant dans 5 secteurs différents dont aucun ne se rapporte à l'informatique. Le SI n'est qu'un outil.
Et comme beaucoup d'entreprises en France, les dirigeants veulent un SI performant, mais sans pour autant investir des centaines de milliers d'euros dedans. Nous sommes plutôt très bien équipés, et dans l'ensemble cela fonctionne bien, mais il y a toujours des améliorations à faire à droite et à gauche... Et ça, c'est mon rôle : développer des scripts pour automatiser certaines tâches, des interfaces entre plusieurs logiciels afin d'uniformiser le SI, récolter des informations auprès de plusieurs sources de données afin de générer des rapports complets, etc...
Donc j'ai beaucoup de boulot, je travaille avec de nombreuses technologies, je fais du web, du scripting, du paramétrage de logiciels tiers, du développement de petits utilitaires, et j'en passe.

C'est très intéressant, et j'essaye d'être très pointu avec les technologies que j'utilise le plus régulièrement (à la base ma spécialité c'est la programmation réseau et les protocoles de communication) et je survole celle où je n'ai besoin que de développer un petit module simpliste. Mon employeur me paye même une formation de 7h à la fin du mois pour l'utilisation du SDK fourni avec le logiciel de gestion commerciale que nous utilisons.

On ne peut en effet être spécialiste de tout, mais on arrive tout de même à en maitriser quelques uns de manière assez poussée.
Et pour 100 employés et 40 postes de travail, il serait coûteux d'embaucher une équipe de 5 développeurs tous spécialisés dans un domaine précis...

[Paul TOTH]

je ne suis pas d'accord, un bon individu ou un mauvais n'engage pas la réussite ni l'échec d'un projet de développement. Il faut arrêter de tout faire dépendre du "pauvre" développeur.
Ce qui prime c'est la méthode de gestion du projet et s'y tenir strictement et rigoureusement.

ça je n'en suis pas certain...un bon développeur pourra sans doute sauver un projet mal géré, donc les contours sont flous et besoins changeants...alors qu'avec un âne tu ne pourras jamais mettre en place une solution même clairement définie... à moins d'avoir un très bon commercial et que la réussite du projet se compte en nombre de 0 et non en satisfaction client...ce qui est cependant souvent le cas ceci dit

[cdosjoub]

Pour beaucoup de personnes et principalement en France, la chimère c'est le développeur (avec une couche chef de projet) qui a 20 ans d'expérience derrière lui et qui par son expérience est capable d'appréhender tous les concepts nécessaires pour la réalisation du projet.
Je réponds donc longue vie aux chimères !

[MichaelREMY]

ça je n'en suis pas certain...un bon développeur pourra sans doute sauver un projet mal géré, donc les contours sont flous et besoins changeants...alors qu'avec un âne tu ne pourras jamais mettre en place une solution même clairement définie... à moins d'avoir un très bon commercial et que la réussite du projet se compte en nombre de 0 et non en satisfaction client...ce qui est cependant souvent le cas ceci dit

un bon programmeur dans un environnement malsain ou incompétent (que ce soit direction, cdp, commercial, MOA) ne peut pas sauver une projet de développement à lui tout seul.
Là encore c'est se donner beaucoup d'importance que de penser que tout dépend que d'un seul homme ou d'une seule ressource.

Une chimère – développeur full stack - peut certainement pallier des compétences absentes dans une équipe, mais ne peut pas combler l’incapacité des autres membres d’une équipe en entreprise.

[Paul TOTH]

Je reprend tes deux interventions car elles se complètent

je ne suis pas d'accord, un bon individu ou un mauvais n'engage pas la réussite ni l'échec d'un projet de développement. Il faut arrêter de tout faire dépendre du "pauvre" développeur.
Ce qui prime c'est la méthode de gestion du projet et s'y tenir strictement et rigoureusement.

selon toi le "pauvre" développeur n'a pas d'importance "ce qui prime" c'est la méthode, si je comprend bien - d'où ma première réponse

un bon programmeur dans un environnement malsain ou incompétent (que ce soit direction, cdp, commercial, MOA) ne peut pas sauver une projet de développement à lui tout seul.
Là encore c'est se donner beaucoup d'importance que de penser que tout dépend que d'un seul homme ou d'une seule ressource.

Une chimère – développeur full stack - peut certainement pallier des compétences absentes dans une équipe, mais ne peut pas combler l’incapacité des autres membres d’une équipe en entreprise.

Quand on a une direction qui ne tire pas les budgets vers le bas, quand le chef de projet fait confiance aux techniciens et donne des directives limpides comme du cristal et que le développeur est capable de traduire cela dans un code beau à faire pleuré...c'est qu'on est chez la bisounours !

de mon expérience, la direction veux toujours plus pour moins cher, le chef de projet est à la ramasse sur la technique mais t'explique comment faire ton boulot, et le cahier des charges et non seulement vaseux mais en plus mouvant, le code de l'application n'a jamais été remis sur le tapis par faute de temps, d'argent, ou de décision. Il y a des portions complètes de code dans lesquelles plus personne n'a mis les mains depuis des années et personne n'ose y toucher de peur que tout se casse la figure.

alors je ne dis pas que c'est le cas partout, mais je dis que c'est le cas souvent, et que c'est souvent les développeurs qui ont conscience du désastre, rarement le chef de projet qui doit rendre des comptes à la direction pour un budget toujours plus serré et qui garde la tête haute en disant que si ça fonctionne comme ça depuis des années c'est que ça ne doit pas être si grave que ça.

Maintenant, est-ce que le développeur va sauver la situation ? probablement pas, car il finit toujours par quitter le navire car il n'en peut plus et qu'il n'est pas assez bien payé pour ne pas rejoindre le chef de projet d'une autre boîte qui lui annonce que ça ne se passe jamais comme ça chez lui - ce qui est faux évidemment - mais au moins il aura négocié une augmentation entre les deux

[Marco46]

Depuis quelques années maintenant, on assiste à une ascension du concept de développeur full stack. Pour rappel, ce terme désigne un type de développeurs fédérant à lui seul nombre de qualités au rang desquelles on peut citer les aptitudes de développeurs front-end, back-end, d’administrateurs systèmes... D’autres pourraient également inclure des compétences telles que le chargé d’assurance qualité ou encore l’analyste des opérations. Bien vrai qu’une définition standard n’a pas encore été arrêtée, on pourrait simplement retenir de manière générale qu’un développeur full stack intègre à lui seule une bonne maitrise des différentes couches de développement d’un projet.

La définition pour rappel ne convient pas.

Un développeur c'est un ... développeur. Toute tâche qui sort du scope du développement est hors sujet. Un développeur full stack ne peut mécaniquement pas avoir pour tâche d'administrer un système, de concevoir / livrer des environnements de dev, d'intégration, de production etc ... Ni même de choisir la composition de la stack (c'est le rôle des architectes).

Un développeur développe, point final. Il conçoit la mécanique interne d'une couche en relation avec le ou les archi, il conçoit la BDD en relation avec la MOA (enfin les gens qui ont la connaissance fonctionnelle du domaine métier), mais il ne fait pas d'administration système ou de tests de perf sur la production.

Par full stack on entend les couches logicielles à développer. Cela part de la persistance des données jusqu'au front de l'utilisateur. Là où ça se complique c'est qu'il y a plein de solutions possibles à chaque couche de la stack.

Donc un développeur fullstack peut maitriser une stack ReactJS / Spring / Oracle (sans être expert dans chaque couche mais simplement compétent) mais être complètement débutant sur une stack Angular / Play / Mongodb par exemple.
Ou encore être débutant en Angular, expérimenté avec Play et confirmé avec Mongodb.

De plus, il évident qu'un développeur fullstack, même spécialisé sur une stack spécifique sera rarement meilleur qu'un expert d'une partie de la stack spécifique.

Après le débat de savoir si le temps perdu du fait du delta de compétence entre un expert sur un sujet et un dev fullstack par rapport au temps perdu dans la communication c'est tellement lié aux personnes et au contexte que c'est impossible d'établir une règle.
La proposition de Adam Bertram est donc parfaitement polémique, probablement à dessein.

TLDR : Développeur Fullstack est composé de 2 termes, certains semblent tout simplement ignorer le premier. Un développeur développe, il ne fait pas d'administration système.