Discussion :

[wolinn]

Ah, quand un programme n'est pas bon du premier coup, c'est un échec? Tu pisses ton programme bon d'un claquement de doigts, sans erreurs, juste parceque tu as tout bien conçu avant? ...

Je n'en suis pas encore là, mais c'est un objectif. En ayant revu mes pratiques, je passe maintenant beaucoup moins de temps au débuggeur qu'il y a 10-15 ans.
Je code aussi plus lentement, mais à l'arrivée, je m'y retrouve en productivité, je ne passe quasiment plus de temps à traquer des erreurs bizarres en exécution pas à pas.

...
Après, si tu me considères comme un échec, ben, comment dire..... Non, moi je considères que nous sommes des humains, avec des failles, et qu'il est normal qu'on trouve des trous dans les specs et dans le codage. Une bonne préparation permet de limiter leur nombre, pas de les éradiquer. Non, un bug au premier jet de programmation n'est pas un échec à mon sens. ça fait partie de la vie. Savoir le gérer correctement est justement ce qui permet de limiter les échecs. Et j'ai un taux de succès des projets sur lesquels je suis passé qui me permet de prétendre que ma manière de travailler fonctionne bien. Je ne dis pas que c'est la meilleure. Je dis juste qu'elle marche bien.

Je ne parlais évidemment pas de toi en particulier. Elle s'applique aussi bien à moi lorsque je dois quand même me résoudre à utiliser un débuggeur. Mon point de vue actuel, qui n'a pas toujours été celui-ci, est que chaque usage du débuggeur résulte d'un "micro-échec", si tu préfères, et de failles dans la méthode, au niveau de la conception ou de la réalisation.

Un exemple que je cite souvent. Un grand assureur veut refaire ses avis d'échéances parce-qu'ils sont moches. Problème, la chaine - de 36 ans d'âge - qui les génère mélange allègrement le formatage des données avec les données elles-mêmes, et est devenue inmaintenable au fil des années...
...

Mon propos ne portait évidemment pas sur du code ancien écrit par d'autres et des situations de reverse engineering. Encore que ça peut quand même signaler un problème de documentation et transmission du savoir-faire.

Après, ça dépend certainement des domaines. Au plus on va vers des algorithmes compliqués, et au plus une analyse préliminaire(et documentée) est indispensable. Sur du complexe, en revanche, avec des centaines de règles imbriquées, pas compliquées en elles-mêmes, mais dont l'empilement est d'une grande complexité, non, initialement écrire un programme faux n'est pas un problème. C'est un point de départ pour mise à jour ultérieure. Ca ne dispense pas d'une réflexion préalable : quelle architecture, quelle données en entrée et en sortie, quelle organisation pour ranger les algos, etc... Mais chercher à faire parfait du premier coup est contre-productif, à mon sens. Cognitivement parlant, voir un algorithme tourner est un outil puissant de compréhension.

Je développe des logiciels de calcul scientifique, de la simulation, avec des méthodes de type Monte-Carlo (donc usage massif de tirages aléatoires), et des simulations qui peuvent durer des heures, du parallélisme, etc., ce qui rend les erreurs très difficiles à traquer. J'ai donc une forte incitation à écrire du code correct au premier jet.
Et on est censé comprendre un algorithme avant de l'avoir codé...

[Brütal]

Toi tu ne manipules pas de Raspberry pi ? Tous les développeurs devraient avoir l'obligation de faire un projet avec un RPI, juste pour prouver qu'ils savent faire autre chose que utiliser des Api toutes faites.

Totalement d'accord.
Surtout qu'avec le Raspberry, y'a largement moyen de faire de passer dans le monde de l'électronique et de faire des projets ultra sympathiques.

Mais en vrai, y'a aussi moyen d'utiliser des APIs toutes faites sur Raspberry XD

[el_slapper]

Je n'en suis pas encore là, mais c'est un objectif. En ayant revu mes pratiques, je passe maintenant beaucoup moins de temps au débuggeur qu'il y a 10-15 ans.
Je code aussi plus lentement, mais à l'arrivée, je m'y retrouve en productivité, je ne passe quasiment plus de temps à traquer des erreurs bizarres en exécution pas à pas.

Pour moi, c'est surtout un effet d'expérience. Je peux aujourd'hui me lancer dans des codes bien plus complexes qu'avant sans préparation ou presque, et être bon quasiment du premier coup. Et, sur des choses plus exigeantes, une bonne préparation me laissera encore moins d'interrogations qu'avant. Pour autant, ça ne réduit pas l'incertitude à zéro. Il y a des choses qui ne rentreront pas dans ma petite tête, et qui nécessiteront toujours des aides cognitives à la compréhension.

Je ne parlais évidemment pas de toi en particulier. Elle s'applique aussi bien à moi lorsque je dois quand même me résoudre à utiliser un débuggeur. Mon point de vue actuel, qui n'a pas toujours été celui-ci, est que chaque usage du débuggeur résulte d'un "micro-échec", si tu préfères, et de failles dans la méthode, au niveau de la conception ou de la réalisation.

Notre désaccord est alors plus philosophique que technique : pour moi, nos cerveaux étant limités, ce genre d'erreurs à la conception est inévitable et ne constitue pas un échec.

Mon propos ne portait évidemment pas sur du code ancien écrit par d'autres et des situations de reverse engineering. Encore que ça peut quand même signaler un problème de documentation et transmission du savoir-faire.

Oui, mais ce genre d'erreurs me parait inévitable aussi. Mon exemple est certes extrême; mais il s'est passé quand même 36 années entre le projet et la refonte. Avec d'innombrables rachats, départs, réorganisations, et autres événements malheureux. C'est pour ça que je suis favorable à du code qui puisse se comprendre lui-même sans documentation. La doc, ça se perd. Le code, ça se conserve. JE préfère adapter mes pratiques aux vrais accidents de la vraie vie plutôt que de faire comme si tout allait bien se passer.

Je développe des logiciels de calcul scientifique, de la simulation, avec des méthodes de type Monte-Carlo (donc usage massif de tirages aléatoires), et des simulations qui peuvent durer des heures, du parallélisme, etc., ce qui rend les erreurs très difficiles à traquer. J'ai donc une forte incitation à écrire du code correct au premier jet.
Et on est censé comprendre un algorithme avant de l'avoir codé...

Mais surtout, ce sont des choses qui sont immuables. Les règles de Monte-Carlo ne vont pas changer du jour au lendemain. Les règles de la comptabilité des assurances ou des hopitaux, si. Nos métiers sont fort différents, ce qui explique notre différence d'approches.

ehh c'est le métier qui génére des algorithmes non ?
stricto sensu on est tous d'accord.
Cependant les "décideurs" et ceux qui dirigent les entreprises, les projets informatiques voudraient l'inverse.
Un nombre élevé d'individus s'imaginent que le numérique et l'informatique bref des lignes de code c'est la panacée et la solution à tous les problèmes
Mais la remarque est fort pertinente

c'est plus compliqué que celà : le métier génère des besoins exprimés de manière fort peu formalisée. Une bonne partie de notre métier est de transformer ces demandes en algorithmes formels exécutables par une machine non consciente. L'autre partie étant évidemment de mettre en place toute la tuyauterie technique pour que ça marche. Donc "le métier génère des algorithmes" ne me parait pas totalement exact. Je dirais que le métier génère un besoin en algorithmes, que nous satisfaisons.

Et je suis d'accord : si le code informatique permet de résoudre un grand nombre de problèmes, ça n'en fait pas une panaçée - ni même la solution la plus pertinente à tous les problèmes

En effet, si un code n'a pas de dette technique alors, pour un changement urgent de fonctionnalité, on peut faire :

• Étape 1 : modifier le code en vitesse pour que le changement soit disponible le plus tôt possible.
• Étape 2 : rembourser tout de suite la dette technique qui s'est ajoutée à l'étape 1. Comme le code est bien couvert par les tests unitaires, on peut se permettre de faire du réusinage de code sans avoir peur de casser ce qui marche.

La dette technique zéro n'existe pas, mais ta méthode me plait quand même. Simplement, quand "ça marche", pour le commun des mortels, "c'est fini". Le problème n'est plus technique, il et humain. D'ou la difficulté de convaincre de faire du refactoring et/ou des tests unitaires automatisés.

[fredoche]

Mince alors, tu m'as percé à jour : oui je suis un vilain hater en série. Merci de me l'avoir rappeler avec tes gentils propos insultants.

Toutes mes excuses d'avoir pollué la discussion sur la formation des développeurs en osant critiquer ton post sur la technique de tracé de disques des jardiniers.

Et pour en revenir à la discussion sur JS, pourquoi tu ne cites pas aussi le fil que j'ai créé ensuite, où je résume 3 jours de boulot sur le sujet en question : https://www.developpez.net/forums/d1...facage-js-cpp/ ?

You are welcome

Technique de la vie réelle mon cher, loin d'être limitée à la jardinerie, mais pour connaitre ce genre de choses, il faut sortir de son bureau et faire autre chose que du C++ à longueur d'année. Cette ficelle, c'est ce qui fera de toi un pro dans de nombreux métiers, de ces métiers qui utilisent la géométrie, la vraie, celle qui utilise l'espace et représente l'espace.

Tu parles du sujet où tu viens pleurer de peur que l'on ne se fiche de toi ?

Au fait tu sais faire voler un papillon sur une page web en JS ?

Ou bien dessiner un cercle avec ton C++ de la mort qui tue, juste en dessinant tous les points, sans utiliser une fonction circle() qui va bien ? Et l'étape d'après c'est le disque toujours en point à point sinon c'est pas drôle. Pas dit que les 2 algos se ressemblent

Moi je me prenais la tête là-dessus à 13 ans, sur un goupil G3 en Basic au club microtel de la "grande" ville du coin. Aussi inutile que le papillon surement
Toi avec tes compétences, tes connaissances en géométrie discrète , ton age et ce langage qui bourrine grave, tu dois faire ça en 2 coups de cuillères à pot non ?

[Invité]

You are welcome

Technique de la vie réelle mon cher, loin d'être limitée à la jardinerie, mais pour connaitre ce genre de choses, il faut sortir de son bureau et faire autre chose que du C++ à longueur d'année. Cette ficelle, c'est ce qui fera de toi un pro dans de nombreux métiers, de ces métiers qui utilisent la géométrie, la vraie, celle qui utilise l'espace et représente l'espace.

Tu parles du sujet où tu viens pleurer de peur que l'on ne se fiche de toi ?

Au fait tu sais faire voler un papillon sur une page web en JS ?

Ou bien dessiner un cercle avec ton C++ de la mort qui tue, juste en dessinant tous les points, sans utiliser une fonction circle() qui va bien ? Et l'étape d'après c'est le disque toujours en point à point sinon c'est pas drôle. Pas dit que les 2 algos se ressemblent

Moi je me prenais la tête là-dessus à 13 ans, sur un goupil G3 en Basic au club microtel de la "grande" ville du coin. Aussi inutile que le papillon surement
Toi avec tes compétences, tes connaissances en géométrie discrète , ton age et ce langage qui bourrine grave, tu dois faire ça en 2 coups de cuillères à pot non ?

Faut arrêter la drogue...

[zecreator]

Tout ça pour dire que si le programme de formation proposé aujourd'hui, inclus exclusivement l'apprentissage des méthodes de production de développement telles qu'on les pratique en entreprise, oui, je pense qu'en 3-4 mois, un novice peut devenir "développeur".

[Marco46]

@zecreator : Mais oui bien sûr. Déjà que je trouve que les BAC+5 sortis de l'école sont aux fraises tu peux m'expliquer comment c'est possible de former un mec en 4 mois alors que les écoles d'ingé n'y arrivent déjà pas en 5 ans ?

[zecreator]

@zecreator : Mais oui bien sûr. Déjà que je trouve que les BAC+5 sortis de l'école sont aux fraises tu peux m'expliquer comment c'est possible de former un mec en 4 mois alors que les écoles d'ingé n'y arrivent déjà pas en 5 ans ?

Parce qu'à une époque, il y avait des tests de logiques à l'entrée de ces formations, et pas seulement un niveau scolaire. Aujourd'hui, si on se retrouve avec des promos de gens qui ne maîtrisent que la moitié des choses, c'est parce qu'il faut former en masse pour répondre à la demande des entreprises. Si les mecs ne sont pas capables d'avoir une mécanique de l'esprit pour visualiser ce qu'ils vont coder avant de le coder, ce métier n'est pas pour eux. Avec l'expérience, les mécanismes d'une fonctionnalité coté "code", apparaît à l'esprit dès l'énoncé du besoin. Perso, je n'ai pas besoin de m'isoler 4 jours pour dire au client si sa fonctionnalité est faisable dans le contexte actuelle ou pas, ça me saute aux yeux tout de suite.

Comprendre les concepts de la POO, de l'implémentation, des tests unit, ça demande pas 5 ans. Sauf si on a pas le cerveau exercé pour ça.

Ce n'est pas une question d'intellect, mais de fonctionnement et de compréhension. Je ne dis pas qu'un développeur doit être surdoué. Mais un niveau de logique au dessus de la moyenne, ça aide grandement. Les gens qui vpont vers ces formations, et qui n'ont aucune pratique du dessin, qui n'ont aucun sens de l'organisation, faut faire autre chose.

[zecreator]

Ce qui me désole, et qui est bien représentatif du monde des développeurs aujourd'hui, c'est que la certification Symphony 2 à plus de valeur aux yeux des recruteurs qu'une certification PHP 7. A croire que ce que l'on veut apprendre aux développeurs, c'est la certitude que l'utilisation des frameworks permettra un bon fonctionnement de leur application, mais sans pouvoir leur dire "Comment".

Les mecs développent, mais sont incapables de dire pourquoi ça fonctionne. ça fonctionne et pis c'est tout...

[el_slapper]

(.../...)
Ce n'est pas une question d'intellect, mais de fonctionnement et de compréhension. Je ne dis pas qu'un développeur doit être surdoué. Mais un niveau de logique au dessus de la moyenne, ça aide grandement. Les gens qui vpont vers ces formations, et qui n'ont aucune pratique du dessin, qui n'ont aucun sens de l'organisation, faut faire autre chose.

Ce n'est même pas une question de logique en général. C'est juste une question d'avoir la tournure d'esprit qui va bien. La tournure d'esprit qui permet d'assumer que la machine n'infère rien, que c'est un vrai bébé, et que si elle ne fait pas ce qu'on veut, c'est qu'on lui a mal parlé. Toujours. Un tas de gens très intelligents et logiques sont infoutus de faire ce métier. Parce qu'il leur manque cette tournure d'esprit.


Nous ne sommes pas supérieurs aux non-programmeurs. Nous sommes différents.


La question qui tue, c'est "peut-on enseigner cette tournure d'esprit?" Ma réponse pas du tout scientifique est la suivante : "à 18 ans, c'est trop tard. Avant, je ne sais pas".

EDIT : pour ton message sur Symphony, c'est l'aveuglement que je cite parfois sur le fait qu'aux yeux des non-programmeurs, notre métier, c'est juste de la maitrise technique. Certes il en faut, mais la capacité à penser algorithmique, à enchainer les décisions formelles, est encore plus importante.

Je prends un mec(soyons sexistes, ça rend l'écriture plus facile) qui est superbon en algorithmique, qui a fait du C toute sa vie, je le mets à COBOL ou à PHP, il va pleurer sa race pendant quelques semaines, maudire ces langages de merde(c.a.d. qui ne correspondent pas à ses habitudes, et ne permettent pas ses petites astuces habituelles), mais il va être productif au bout de quelques semaines. Malheureux, sans doute, mais productif. Alors que je prends le premier gnou venu qui a appris par cœur toutes les astuces du COBOL(ou du PHP), qui saura répondre de tête qu'un cylindre,c 'est 840 000 octets(ou une question quizz équivalente sur PHP, dont je ne sais rien), et je lui demande de bosser..... Ben il va vite plafonner. Parcequ'il lui manque la tournure d'esprit dont on a besoin dès qu'on fait des choses un peu plus futées que de l'assemblage. Il comprendra ce qu'il faut faire, je part du principe qu'il est intelligent, mais il ne sera pas à même de découper tout ça en micro-décisions compréhensibles par la machine.

C'est la seule et unique différence entre un gnou et un professionnel efficace. Après, il est des professionnels efficace plus ou moins futés, plus ou moins motivés, plus ou moins techniques, etc..... Mais le professionnel efficace saura faire un fizzbuzz (ou trouver la deuxième valeur la plus élevée d'une liste, ou programmer l'opération qui transforme [1,2,3,2,3,4,3,5] en [1,2,4,3,5])sans même remarquer que ça lui prend un effort. Certains mettront 5 minutes, d'autres 15 minutes, certains auront des bugs et les corrigeront, d'autres pas, mais tous y arriveront et se demanderont ou était la difficulté. Le gnou ira chialer parce-qu'aucun de ces trois exercices ne correspond aux algorithmes classiques qu'il a appris en cours. Alors même qu'il est intelligent, motivé, technique, et tout.

[Jamatronic]

@el_slapper : Je donnerais bien +1000 à ton message si cela était possible.

[Invité]

tu peux m'expliquer comment c'est possible de former un mec en 4 mois alors que les écoles d'ingé n'y arrivent déjà pas en 5 ans ?

Parce que les écoles d'ingé ne forment pas des développeurs mais des gestionnaires et des chefs de projet. Sur 5 ans, il y a assez peu d'informatique en fait : pendant les 2 ans de classes prépa, tu fais surtout des maths et pendant les 3 ans restants, tu fais pas mal de matières genre anglais, gestion de projet, gestion d'entreprise, compta, marketing... Bien sûr, je caricature car il y a des écoles avec de très bonnes formations en informatique mais il y a souvent plus d'info à la fac.
Donc "former un mec en 4 mois" c'est exagéré mais en 3 ans ça doit être possible en supprimant les matières "annexes" et les matières théoriques.

[zecreator]

Parce que les écoles d'ingé ne forment pas des développeurs mais des gestionnaires et des chefs de projet.

Carrément d'accord. J'ai jamais vu un mec sorti d'école d'ingé, faire toute sa carrière comme dev. Ils font ça 2 ou 3 ans, et ensuite ils veulent faire de la gestion d'équipe. En fait, c'est le principal objectif à la sortie de ces formations : ne pas resté un exécutant derrière son écran, avoir des responsabilités.

On mettra ça sur le compte de l'ambition, ou d'un plan de carrière, mais du coup on se retrouvera bientôt avec plus de chef de projets qu'il n'y aura de développeur pour produire.

A croire que le métier de développeur, c'est franchement le bas de l'échelle et ça pue...

[foetus]

plus de chef de projets qu'il n'y aura de développeur pour produire

Et pourtant non avec le "near shore" ou "offshore". Et donc de l'ingénieur BAC+5 MOA pour diriger tout cela : projets/ équipes internes/ équipes externes.
Et, je peux me tromper, mais tu vois que depuis 4 ans cela ne prend pas trop parce qu'une grosse partie des étrangers ne sont pas bon techniquement, mais dans les offres d'emploi, les E.S.N.s "se préparent" en demandant de plus en plus : bilingue anglais, gestion de projet (en insistant sur la planification des tâches), expérience significative, références professionnelles ...
Mais bon à terme, on peut penser que des "échanges de formations" entre la France et l'Inde/ Chine vont arriver : nous sommes gentils en France.


Justement aux États-Unis, Microsoft (mais sûrement pas que) veut des réformes pour pouvoir employer des travailleurs étrangers.
En France, on a un précédent: le personnel hospitalier qui vient des pays de l'Est.

[zecreator]

Les métiers de production n'ont jamais eu la cote. Dès qu'il s'agit d'exécuter "des ordres", ça donne l'image du "troufion" qui n'a aucune ambition, et qui n'est bon qu'à appuyer sur un bouton. En développement, c'est pareil. L'idée de rester développeur est impensable pour beaucoup de mecs sortis d'école d'ingénieur. Pour eux, ce serait un échec car dans leur esprit, il n'ont pas fais ingé pour rester "en bas de l'échelle". Ils sont destinés à de plus hautes fonctions.

Comme disait Oscar Wilde : "L'ambition est le refuge de l'échec.", et des ambitieux dans ce métier, qu'est-ce qu'il peut y en avoir.

[fredoche]

Tu généralises beaucoup zecreator quand même non ?
Ne reste t'il pas des ingénieurs qui auraient le gout de la création, de la recherche de solutions, de la technique ? Car c'est ça le métier à la base non ?
S'ils veulent tous faire chef, faut faire des écoles de management, pas d'ingés non ?

Enfin bon... Mon 1er voyage blablacar je l'avais fait avec un mec, un jeune de 26-27 ans qui sortait de l'ENSAM de Chalon en Champagne, qui venait de passer 2-3 ans sur Louvois, pour une SSII que j'ai oublié, mais dont il était ressorti grillé (burn-out). Employé à piloter des réunions et pondre des rapports toutes les semaines, il était pas fait pour ça et la pression était terrible.

Peu importe on a bien discuté, et lui sachant que j'étais un développeur web depuis des décennies, on a beaucoup échangé technique. Il a souhaité me montrer l'appli qu'il avait développé, pour une connaissance professionnelle, un peu au black mais peu importe. Un gros truc en Excel qui faisait de la gestion de catalogue produit et de pricing, pour faire du devis et de la facturation. Tout était fait en Excel, donc tous les liens de données.

En gros le gars avait réinventé la roue, mais bien entendu sans tous les avantages d'un SGBDR même basique.

Curieux je lui demande s'il connait le SQL ? non . MERISE ? non . Les SGBD ? Alors oui ils avaient eu une formation équivalente à 40h sur Access.
Donc évidemment je lui parle de tous les avantages essentiels de ce type d'outils dont ACID, intégrité référentielle, transactionnel,... et tous les aspects pratiques que cela peut résoudre.

Le hic n'est il pas là ? Un gars sorti d'une école assez prestigieuse mais que l'on forme a des techniques et des outils inutiles ou presque dans un environnement professionnel autre que de l'artisanat de quartier ?
Et à qui en plus on bourre le crane de tas de technologies différentes, pas forcément en rapport avec l'informatique, genre electro-tech ou -nique, mecanique, RDM, sciences, etc... plus tout le coté management, gestion...

A coté de ça un mec qui fait 4 mois d'info, c'est 4 mois plein.
Combien d'ingés font 4 mois plein d'info sur leurs 3 ou 5 ans de formation ? Et ils apprennent quoi en fait ?
Quels sont les référentiels en fait en école d'ingénieur ? Quand tu vois qu'un mec en école d'ingé prestigieuse fait une semaine d'Access en tout et pour tout pour traiter de l'information, ce qui est à la base même de l'informatique.

Alors que dans les universités, les références sont internationales, j'imagine mal les mecs bosser sur des trucs comme Access non ?

Foetus, ça fait 20 ans que l'on nous fait craindre le off-shore. A part sur des procédures très standardisées, qui y gagne vraiment sinon ceux qui promeuvent et vendent ce off-shore ? Ca fait 20 ans qu'on nous dit que tout va partir en Inde, Bangalore capitale mondiale de l'IT... Mais je ne le vois pas effectif ça 20 ans après, et la demande locale est toujours forte.

Simondecoline, désolé, moi c'est comme Obelix, une seconde nature en quelque sorte ... Au fait tu sais concevoir une BdD relationnelle ? Et l'exploiter ?

[fredoche]

Pour le plaisir, je fus et reste un grand fan de TF2 :

...I solve practical problems...

[foetus]

Foetus, ça fait 20 ans que l'on nous fait craindre le off-shore ? A part sur des procédures très standardisés, qui y gagne vraiment sinon ceux qui promeuvent et vendent ce off-shore ?

Et pourtant cela devient une réalité :

• Une majorité d'assistances téléphonique sont en Tunisie/ Maroc/ Algérie.
• Les boites de jeux (mais sûrement pas que) ont de + en + de développeurs dans les pays de l'Est (parce qu'eux ils sont bon techniquement, le décalage horaire/ déplacements ne doivent pas être trop conséquents)
• Une société comme ArkeUp travaille avec Madagascar.

[fredoche]

Oui évidemment tu pourras citer plein d'exemples notamment pour ces taches type centre d'appels et hotline - support 1er niveau, mais c'est justement le basique, le subalterne.

Maintenant les call-centers localisés en France et sans accent sont devenus un argument commercial tu le sais ça aussi ?

En tout cas les call-centers en France ça marche fort aussi. La boite locale B2S à chalon marche bien et depuis des années

Pour les devs de jeux, oui les gens de l'Est sont très forts, et l'ont toujours été. J'ai une pensée pour Croteam par exemple, pour un de mes jeux préférés là aussi.
La qualité prime pour le jeu, pas forcément le cout humain.
Vu que j'ai commencé dans ce milieu de l'info en sous-traitance d'Infogrames, je sais le sujet assez compliqué. Les studios de dev sont partout dans le monde.

[foetus]

c'est justement le basique, le subalterne.

Et justement, jusqu'où va le rôle du "subalterne" ?

Parce que dans le passé, j'ai eu un contact pour une formation E.S.N. de petit chef base de données. En gros, c'est toi qui fait la conception et les réunions et tu pilotais 1 ou plusieurs développeurs dans le maghred "pour faire les réglages".
Donc effectivement, ce n'est pas un rôle de développeur, mais cela devient un rien technique.