Discussion :

[ppboy]

Bonjour à tous,

Je fais une recherche d'informations sur le poste de développeur informatique.
Dans les grandes lignes, j'aimerais savoir comment se passent les missions du développeur, je n'ai encore vécu aucune expérience professionnelle dans ce domaine, et aimerais me faire une idée de ce qu'est réellement la fonction de développeur informatique.
J'aimerais des témoignages de missions effectuées particulièrement dans les langages type java, C#, ou langages de bases de données mysql, python.

Qu'est-ce qui vous est demandé de faire?

PS: Je prle de "mission" en références aux missions effectuées par les développeurs freelances, mais même pour les non-freeances, s'il est possible d'avoir quelques témoignages sur des projets concrets effectués en entreprise, à savoir qu'est-ce qui vous était demandé de faire précisément selon le langage utilisé (ceux demandés ci-dessus).

J'espère formuler ma demande assez clairement, merci beaucoup!

[Glutinus]

Demande assez surprenante : tu trouveras des descriptifs du métier de développeurs un peu partout sur le net, et sur ce forum en particulier...

Petite remarque : tu ne donnes très peu d'information sur tes connaissances dans ce domaine, si t'as commencé une formation ou à la recherche d'une formation / reconversion.

Dans les grandes lignes :
- un développeur conceptualise d'abord son application, c'est-à-dire il fait des schémas, il balance ces idées, il anticipe les écueils, bref, c'est comme faire le plan d'une rédaction.
- il développe donc tape les différents fichiers de code et les exécute
- il teste avec l'aide de la maîtrise d'ouvrage (des gens qui font le pont entre lui, technique, et les utilisateurs) que les fonctionnalités qu'il a codées sont bien celles attendues. A noter qu'il y a de moins en moins d'AMOA, le développeur se retrouve souvent confronté directement auprès d'un client...
- il prépare les livraisons, c'est-à-dire les composants qu'il a bâti en bac à sable dans le but de le mettre sur un environnement de production
- il maintient l'application, c'est-à-dire qu'une fois que l'application est en production, celle-ci peut générer des anomalies. A noter que beaucoup d'utilisateurs mettent la pression pour faire la livraison sans pour autant tester, car c'est plus simple d'avoir le produit sous le nez, buggé et de taper sur les gens. En général c'est compliqué car si c'est assez rapide de corriger en début de projet, corriger en production prend souvent plus de temps à cause de nouveaux process de validations.
- il fait beaucoup de communication, de mail, de diplomatie, pour faire accepter ce qui est logique, et refuser les demandes illogiques

Concernant les langages, ce ne sont juste que des langages, qui ont des fonctionnalités différentes. Le java et C# sont des langages dits "objet" qui se ressemblent, mais ce sont des concepts que je ne peux expliquer en quelques lignes si tu ne sais pas développer.
mysql permet de requêter sur des bases de données, c'est-à-dire que tu as tes "tables" (dans le sens tableaux) et ce langage permet d'y glisser des lignes, les mettre à jour, modifier la structure de ces tables et surtout sélectionner et calculer le lot de données dont tu as besoin.
il y a des langages orientés mathématiques, des langages systèmes, etc. ça c'est à voir en cours de formation voire début de travail (je suis passé du langage pour faire de l'embarqué c'est-à-dire sur des microsystèmes en temps réel, pour faire du java et finalement terminé dans la donnée)

Concernant les freelances / non-freelances, c'est encore une autre dimension du travail.
Le freelance a monté sa boîte et doit chercher son client (ou se faire aider), fait sa comptabilité, et il ne facture que lorsqu'il travaille. Il a tendance à gagner un peu plus, mais cela compense le risque de ne pas avoir de mission et de ne pas facturer.
Le non-freelance (a priori, CDI ou CDD) peut travailler chez un employeur, une agence web, ou dans le service.

[Daletho]

Pour essayer de compléter ce qu'a déjà pu dire Glutinus, toutes les missions ne se ressemblent pas, ça dépend déjà beaucoup de l'environnement, si tu es seul ou fait partie d'une équipe de développeurs, comment fonctionne l'équipe (SCRUM, TDD, code review...), si tu travailles en régie ou au forfait etc.

Dans mon cas, je suis développeur fullstack (presta en CDI) et je suis seul sur les missions dont j'ai la charge. Cela veut dire que lorsque le client manifeste le besoin d'une solution applicative, je dois alors rencontrer différentes personnes pour approfondir ce besoin, cerner son périmètre, vérifier que ce besoin n'est pas déjà couvert par une autre application existante, proposer une solution technique etc.
Une fois que le besoin est bien identifié et validé par la DSI, je m'occupe de modéliser la base de données, de créer les écrans avec toute la logique métier qui va bien derrière, bref je développe la solution. A savoir que dans mon cas je n'ai jamais pu obtenir un cahier des charges qui ne bouge pas en cours de mission, du coup il peut y avoir quelques aller retour entre le client et moi. S'il y a quelque chose qui m'a le plus étonné lors de mon entrée dans la vie active, c'est ce point là. Durant mes études j'ai du effectuer un certains nombre de projets bien définis et figés alors qu'en condition réelle on se rend compte assez souvent que le client ne sait pas lui même tout à fait ce qu'il veut... il faut alors savoir parler le même langage que lui (ce qui peut être compliqué en tant que dév junior ou chez un nouveau client), l'aiguiller, le conseiller, savoir mettre des limites sur les besoins exprimés, savoir être diplomate aussi car le client peut changer d'idées en cours de développement (et ça peut impliquer bien plus de changements que ce qu'il imagine) etc.
Quand la maquette est OK, je peux alors mettre en place diverses interfaces pour gérer les flux de données entrant et sortant entre l'application et d'autres déjà existantes. Par exemple il m'arrive fréquemment de m'alimenter depuis les données d'un ERP et d'alimenter en retour une application de BI.
Je met alors à disposition une version de test afin que les utilisateurs clés puissent me confirmer qu'aucun bug que je n'aurai pas décelé n'existe, que les calculs sont bons etc.
Quand tout est OK, je nettoie les données et déploie l'application en prod. Je suis ensuite amené à intervenir pour la faire évoluer ou corriger d'éventuels bug.

Je gère donc mon planning moi même, je me constitue une to do list et chaque jour je la met à jour en fonction de mon avancement.
Mais dans une équipe de développeurs, un chef de projet s'occupe de la distribution des tâches entre les différents développeurs.

Je ne suis pas sûr de savoir quoi te dire concernant les langages de programmation. Actuellement je fais du C# pour des appli accessibles depuis un navigateur, du coup il y aussi de l'ASP.NET, de l'HTML, du CSS et JS avec divers frameworks et bien entendu du SQL. Mais je suis également amené à faire un peu de BI avec QlikView ou faire des scripts batch ou VBA selon les besoins.
En soit je ne pense pas que cela soit le point le plus important concernant le déroulement d'une mission.

[ed73170]

Ce que décrit Glutinus serait la réalité si tout se passait pour le mieux dans le meilleurs des mondes, c'est à dire si le développeur était responsable de ses applications du début à la fin. Cela a certes existé dans un passé lointain, mais ce n'est malheureusement plus le cas. Aujourd'hui, un développeur se contente dans beaucoup de missions de faire ce qu'on lui dit de faire sans discuter.

Énormément de missions consistent maintenant à maintenir des applications (très) anciennes que personne ne veut réécrire car cela coûterait trop cher, alors on met des rustines, voire des rustines sur d'autres rustines plus anciennes.

On a inventé les méthodes agiles pour soit-disant renforcer la proximité entre les clients et les développeurs, mais tous ceci ne sert qu'à masquer le désir d'interchangeabilité des développeurs de la part des SSII, et donc leur remplacement rapide. Et ce ne sont pas les dernières modifications du code du travail qui vont améliorer les choses.

Un développeur peut aussi ne rien faire si le client souhaite avoir quelqu'un de présent en cas de problème, cela m'est arrivé sur une mission de plusieurs mois où mon temps de travail effectif tournait autour de 3 heures par semaine. Le reste du temps il fallait bien s'occuper sans que cela ne se voie trop, car bien sûr le client souhaite que dans ces cas là on fasse semblant de travailler même si on n'a rien à faire.

[Glutinus]

Haha, je m'excuse pour mon pavé qui va suivre, je préfère attendre les réponses de l'auteur pour comprendre ses attentes car ses questions sont génériques. Si ça se trouve, c'est un développeur en herbe qui commence une licence et qui veut savoir comment ça se passe "pour de vrai" !

Ce que décrit Glutinus serait la réalité si tout se passait pour le mieux dans le meilleurs des mondes, c'est à dire si le développeur était responsable de ses applications du début à la fin. Cela a certes existé dans un passé lointain, mais ce n'est malheureusement plus le cas. Aujourd'hui, un développeur se contente dans beaucoup de missions de faire ce qu'on lui dit de faire sans discuter.

En fait, dans un monde idéal, chacun aurait un poste qui lui conviendrait. Il y a des personnes très spécialisées qui ne veulent faire qu'une seule chose et se plaise et sont très performent dans la mono-tâche, mais n'apprécient pas d'être "transverses". Et d'autres qui veulent suivre l'ensemble d'un projet et se retrouvent cantonner à un seul élément de la chaîne sans avoir de vision en amont et en aval. Pour donner un exemple, dans les équipes Business Intelligence il y a une partie "alimentation" c'est-à-dire gestion de la donnée, et une partie reporting. Officiellement, l'ingénieur BI fait l'interview de l'utilisateur, modélise sa base de données, fait l'alimentation, créé les reportings. Dans les petites boites, c'est le cas. Dans des grosses structures l'ingénieur BI peut faire qu'une seule de ces tâches, voire une seule.

Actuellement je suis dans une structure plus petite, les chefs de projet ne font pas du tout de la spécification ou du management, mais une sorte de "traduction" des envies des utilisateurs. De ce fait tout ce qui touche de prêt ou de loin à un écran ou une souris est délégué au développeur. On ne porte pas ce titre mais un trigramme en franglais un peu pompeux, mais dans les faits on développe quasiment depuis l'interview client jusqu'à la maintenance de l'application.

Énormément de missions consistent maintenant à maintenir des applications (très) anciennes que personne ne veut réécrire car cela coûterait trop cher, alors on met des rustines, voire des rustines sur d'autres rustines plus anciennes.

Effectivement, j'ai répondu assez directement car le développeur, étymologiquement "développe", donc on croirait qu'il fait une application de A à Z. Dans les faits, on peut se retrouver sur une application à maintenir. J'ai personnellement pendant 18 mois surveillé une application, et quand ça buggait, ce n'était pas de mon ressort (soit les fichiers en amont étaient mauvais, soit les serveurs tombaient, soit la base de données était pleine). Je n'étais alors même pas "mainteneur", mais "superviseur", ou pousse-mails pour être moins poli.

Le problème étant que dès que tu veux ne serait-ce appliquer une rustine sur rustine, comme dit ed73170, il faut limite plus de paperasse que pour appuyer sur le bouton de la valise de l'arme nucléaire. Mais comme disait le grand sage el_slapper (un autre membre du forum), le mieux est de passer la rustine en loucedé.

On a inventé les méthodes agiles pour soit-disant renforcer la proximité entre les clients et les développeurs, mais tous ceci ne sert qu'à masquer le désir d'interchangeabilité des développeurs de la part des SSII, et donc leur remplacement rapide. Et ce ne sont pas les dernières modifications du code du travail qui vont améliorer les choses.

Je pense sincèrement que les méthodes agiles ont été inventées par des gens qui voulaient faire avancer les choses dans le bon sens. Le problème, c'est qu'aujourd'hui (comme depuis longtemps) le but de l'être humain est de détourner les choses pour n'en garder que ce dont il a envie. Les personnes incompétentes voire malveillantes en feront l'usage. De ce fait, les méthodes agiles disent souvent que l'utilisateur doit s'impliquer en plus de valider. Aujourd'hui, c'est l'inverse : l'utilisateur ne s'implique plus, et ne prend même plus la peine de valider. Je pense que cela est dû aux produits finis du GAFA : les utilisateurs ont à disposition des milliers d'outils sur le net ou en application, ils gardent ceux qu'ils préfèrent et oublient les autres. Ils attendent de même d'une application dans un contexte professionnel : avoir une appli qui devine et créée leur besoin, qu'ils n'ont pas besoin de valider, et utiliser le SAV à l'envi. Ce n'était évidemment pas comme ça dans les années 90 ou avant, là où il y avait des AMOA et de MOA.

Pour revenir sur les méthodes agiles, exit les implications clientes, mais par contre la réunion hebdomadaire se transforme en réunion quotidienne, l'adoption du fameux "stand-up meeting" (petite réunion informelle de cinq minutes pour définir les objectifs de la journée) qui devient un sitting formel et qui dure 2h tous les matins, mais fait bien mousser les chefs de projet qui ne comprennent rien à ce qu'ils font.

Un développeur peut aussi ne rien faire si le client souhaite avoir quelqu'un de présent en cas de problème, cela m'est arrivé sur une mission de plusieurs mois où mon temps de travail effectif tournait autour de 3 heures par semaine. Le reste du temps il fallait bien s'occuper sans que cela ne se voie trop, car bien sûr le client souhaite que dans ces cas là on fasse semblant de travailler même si on n'a rien à faire.

Idem, j'ai fait là-haut une description comme on peut avoir sur l'ONISEP, qui n'est pas dans le faux, mais pas dans le vrai non plus. Il y a des milliers de "métiers" de développement différent, tout dépend de la taille de l'équipe, de l'organisation, du budget, de l'état d'esprit du client, de la cible, du type de projet (on fait pas pareil un projet business intelligence ou une landing page en web). Mais ce serait pareil dans d'autres métiers, tu prendrais un "analyste portefeuille" chez Banque A, il ne fera pas du tout le même métier qu'un analyste portefeuille chez Banque B. Et pourtant la fiche Onisep listera les tâches qui est habituellement fait, ou en commun, ou en théorie.

[Derek Corgan]

Ce que décrit Glutinus serait la réalité si tout se passait pour le mieux dans le meilleurs des mondes, c'est à dire si le développeur était responsable de ses applications du début à la fin. Cela a certes existé dans un passé lointain, mais ce n'est malheureusement plus le cas. Aujourd'hui, un développeur se contente dans beaucoup de missions de faire ce qu'on lui dit de faire sans discuter.

J'ose espèrer que cela existe encore

Énormément de missions consistent maintenant à maintenir des applications (très) anciennes que personne ne veut réécrire car cela coûterait trop cher, alors on met des rustines, voire des rustines sur d'autres rustines plus anciennes.

Au bout d'un moment l'application n'est plus constituée que de rustine et devient totalement rigide (et cher à maintenir). Reste à trouver la personne courageuse qui va prendre le risque et la responsabilité de dire stop il faut tout casser, accepter de dépenser plus pendant quelques temps afin de gagner en cout de maintenance, reactivité aux de la demandes de la MOA ....

On a inventé les méthodes agiles pour soit-disant renforcer la proximité entre les clients et les développeurs, mais tous ceci ne sert qu'à masquer le désir d'interchangeabilité des développeurs de la part des SSII, et donc leur remplacement rapide. Et ce ne sont pas les dernières modifications du code du travail qui vont améliorer les choses.

Les SSII détournent l'usage des méthodes agiles dans leur propre intérêt (Vendre un max de dev avec un max de marge)
A la base les méthodes agiles proviennent de développeurs expérimentés qui souhaitaient se rapprocher de l'utilisateur afin de mieux valoriser leur expérience. Face à la tendance consistant à avoir plus de développeurs plus loin mais moins cher (offshore), les méthodes agiles permettaient de produire mieux (des applis) avec moins de développeurs qui sont proches bien qu'ils soient plus cher. Les méthodes agiles n'étaient pas faites pour servir l'intérêt des SSII.

[ppboy]

Heyyy!
Oui désolé, il était 5h du mat, j'étais fatigué j'ai pas été aussi complet que ce que je croyais.
En tout cas, merci déjà pour toutes ces réponses, pour être tout à fait honnête ce message est plus un remerciement qu'une réponse, j'ai pas eu le temps de tout lire!

Mais, en gros, je fais de la programmation à l'école depuis bientôt 4 ans (j'en faisais en autodidacte avant, avec l'école depuis 2), j'ai juste jamais eu d'expérience professionnelle, et je me demandais ce qu'un développeur faisait concrètement au quotidien. Dans les grandes lignes j'ai (HEUREUSEMENT) bien saisi le truc, mais, dans la vie de tous les jours, qu'est-ce que mon employeur va me demander de faire, là était la question, comme déjà dit j'ai aucune expérience professionnelle et je sais que cours =/= travail et voilaaa, je voulais un aperçu de ce qu'était vraiment le terrain.
J'ai vu dans ma lecture en diagonale quelques éléments de réponse, en tout cas merci bien je relirai tout à tête reposée, en attendant les langages envoyés en haut sont les langages que je maîtrise, c'est pour ça que je demandais des exemples pour ces langages là précisément (puisque le travail n'est évidemment pas le même selon que tu programmes en java ou en mysql)


Désolé, j'écris tard ici, en bout de vie après des sessions de révisions assez lourdes, fatigue du cerveau

[Mat.M]

Les SSII détournent l'usage des méthodes agiles dans leur propre intérêt (Vendre un max de dev avec un max de marge)

c'est un non-sens....

1 une méthode à quoi ça sert ? Une méthode ça sert à conjuger un ensemble de moyens en vue d'une finalité,objectivité.
Dans un environnement industriel une ou des méthodes c'est une manière de procéder pour réussir et mener à bien un projet industriel.

Une entreprise qui ne met pas des méthodes est vouée à couler et disparaître.

Pour ce qui est de détourner une méthode , une méthode est là basiquement ou fondamentalement pour inspirer des manières de faire c.a.d. qu'il faut l'adapter à des besoins spécifiques à l'entreprise.
Autrement dit ce n'est pas un dogme comme un dogme religieux qu'il faut appliquer à la lettre.
D'ailleurs nombres de méthodes informatiques ne sont certainement pas adapatées à des petits projets sinon c'est enfoncer des clous avec un rouleau compresseur.

2-pour ce qui est de gagner de l'argent bah oui la SSII a intérêt de gagner de l'argent sinon elle ne verse pas votre salaire et pour ce qui est de la marge ben pas de marge pas d'augmentation de salaire.

Pour finir le monde de l'informatique et de l'emploi en informatique je l'ai déjà écris c'est essentiellement et substantiellement des processus industriels ce n'est pas de l'artisanat à vocation singulière.
Faire du développement informatique ce n'est pas de la poésie ni de la littérature c'est une technique industrielle...
Sinon vous risquez de perdre votre temps et vous feriez mieux de vous reconvertir dans l'artisanat ou les métiers artistiques.

A la base les méthodes agiles proviennent de développeurs expérimentés qui souhaitaient se rapprocher de l'utilisateur afin de mieux valoriser leur expérience.

en trame de fond c'est l'éternel débat entre générique et spécifique.
Or coller au besoin des utilisateurs de manière particulière cela induit des développements spécifiques ce qui finit par être coûteux

[ed73170]

2-pour ce qui est de gagner de l'argent bah oui la SSII a intérêt de gagner de l'argent sinon elle ne verse pas votre salaire et pour ce qui est de la marge ben pas de marge pas d'augmentation de salaire.

Tu as déjà vu une SSII qui redistribuait la marge a ses salariés ? Comme toute entreprise moderne la SSII et là pour faire de la marge, la distribuer aux actionnaires, et expliquer aux salariés que vu le contexte économique difficile, il n'y aura pas d'augmentation cette année, ou alors 0.01% mais cela nous coûte un gros effort alors il faudra être bien reconnaissant.

[Mat.M]

Tu as déjà vu une SSII qui redistribuait la marge a ses salariés ?

je n'en ai pas vu mais avec la crise économique passée une entreprise qui renoue avec le profit ça ne peut être que mieux

[Pol63]

dans la vie de tous les jours, qu'est-ce que mon employeur va me demander de faire, là était la question

bah des fois on va te dire "faut rajouter un module sur tel soft, donc un bouton de menu et quelques pages qui vont avec"
donc tu réponds "ok c'est pour gérer quoi"
là soit on te donnes les détails (réunion avec des "il faut telles colonnes, un bouton pour faire ca ..."), soit tu vas en discuter avec le client pour comprendre ce qu'il veut faire et le traduire en "ok je vais vous mettre un tableau avec telles colonnes et un bouton pour faire ca"
donc soit tu tombes sur un key user efficace qui va té répondre "oui mais avec une interface comme ca ca serait plus pratique" soit tu tombes sur le mauvais qui va te dire "et faudra que je clic sur le bouton ? à chaque fois ?"
après tu poses ton bouton, ton tableau, tu tapes un peu de code, tu testes et tu dis "j'ai fini"
(et là des fois ton chef il reteste derrière et revient en te disant "t'es sur que t'as testé ???")
ca peut prendre une demie journée ou deux semaines ...

après dans la phase de dev il peut y avoir un peu de test dans un projet vide pour être sur que tel truc fonctionne bien comme tu le penses, quel truc est le plus rapide, un peu de lecture sur l'aide, ou les forums, ou à discuter avec un collègue pour faire un choix entre telle méthode ou telle autre (parce que tout code peut s'écrire d'autant de manières qu'il y a de développeurs)

il y a aussi des corrections de bugs, au mieux tu as un truc genre "quand je clic ici puis là puis que j'écris ca et qu'il est moins de 8h du mat ca plante", au pire tu as "des fois sur cette page ca plante"
dans le 1er cas tu refais ce qu'on te dis pour vérifier que ca plante bien, tu corriges et tu retestes pour valider la correction pour livrer
dans le 2ème cas tu passes des heures à cliquer partout et à écrire n'importe quoi pour que le bug apparaisse (ou avec un peu d'expérience tu réponds "bah quand tu m'auras dit concrètement comment le faire planter je regarderais pour corriger" ^^

et y a des boites où on te file le boulot presque au fur et à mesure, et d'autres ou tu auras une liste de dizaines de trucs à faire dans les semaines à venir et à toi de t'organiser en fonctions des priorités

[Pyramidev]

il y a aussi des corrections de bugs, au mieux tu as un truc genre "quand je clic ici puis là puis que j'écris ca et qu'il est moins de 8h du mat ca plante", au pire tu as "des fois sur cette page ca plante"
dans le 1er cas tu refais ce qu'on te dis pour vérifier que ca plante bien, tu corriges et tu retestes pour valider la correction pour livrer
dans le 2ème cas tu passes des heures à cliquer partout et à écrire n'importe quoi pour que le bug apparaisse (ou avec un peu d'expérience tu réponds "bah quand tu m'auras dit concrètement comment le faire planter je regarderais pour corriger" ^^

Non. Pour prévoir le cas fréquent où l'utilisateur ne donne pas assez d'infos, il aurait fallu programmer de telle sorte que le logiciel écrive dans un fichier de log les informations pertinentes, dont les actions de l'utilisateur (ex : sur quels boutons il a cliqué) et les erreurs détectées.
Ainsi, il suffit de demander à l'utilisateur de faire une manip qui envoie le fichier de log. En analysant le fichier de log, on gagne alors beaucoup de temps.
D'ailleurs, si un tel fichier de log existe, alors il ne devrait pas être lu tout de suite par le développeur, mais d'abord par le centre d'assistance, afin de faire un filtre sur les problèmes qui ne viennent pas d'un bogue du logiciel, mais d'une cause extérieure, par exemple un échec de connexion au réseau, une absence de droit d'écriture sur un fichier ou une lecture d'un fichier qui ne respecte pas le format exigé par le logiciel.

après tu poses ton bouton, ton tableau, tu tapes un peu de code, tu testes et tu dis "j'ai fini"

Il y a plusieurs niveaux de « j'ai fini » qui vont de « ce sera fonctionnel le jour J, mais il reste du travail à faire si on veut éviter de diminuer la productivité à long terme » à « j'ai fini de mettre à jour le code, dont le réusinage, les contrôles d'erreur, l'écriture dans les logs et les tests unitaires (c.-à-d. les tests automatisés), et j'ai aussi mis à jour la documentation utilisée en interne ».
Il est important de préciser ce qui est fait, ce qui est non fait et quelles seront les conséquences si ce qui est non fait est abandonné du planning.