Discussion :

[xyvamylapp]

Bonjour à tous,

Développeur depuis environ 1 mois dans une petite entreprise qui édite un logiciel de gestion (il s'agit d'ailleurs de ma première expérience professionnel), je me pose de sérieuse question quand à la manière de travailler de cette boite...

Replaçons un peu le contexte:

L'entreprise ou je suis édite un logiciel qui à environ 20 ans et qui à donc vu passé bon nombre de développeurs.
L'entreprise, pour résumer brièvement, est extrêmement en retard sur les versions de ses outils
Le logiciel, développé avec PHP (5.3) pour le back, PostgreSQL(oublié la version) pour la db et pour le front..... XUL.
Pas de framework utilisé.

Mon travail, consiste surtout a réglé des soucis des clients, qui appelle car la liste des utilisateurs affiche 29/30 enregistrements ou bien a corrigé des "anomalies"

Quand je suis arriver dans l'entreprise, 3 choses me sont sauté au yeux, peut-être du a mon inexpérience du milieu professionnel, c'est pour cela que je demande.

- Zéro documentation:
L'entreprise à crée le logiciel mais ne possède aucune documentation, aucun schéma sur les éléments de l'application, certain bout de code sont commenté, plus ou moyen clairement mais à part cela, rien de précis.
Je soupçonne l'entreprise de ne pas connaitre complètement son logiciel

- Une base de donnée problématique?:
La bdd m'énnerve. Aucune liaison étrangère et des colonnes qui m'ont l'air totalement inutiles (nom, prenom, nom_prenom, date de naissance, age) <== chercher les erreurs
Elle est tellement problématique que chaque problème client concerne des "données fantômes" ou des reliquats qui se trouve dans la bdd.

- La méthode de travail pour aider les clients:
Quand un client a un problème (liste des utilisateurs affiche 29/30 enregistrements par exemple), après que le support ai essayé différente chose, le problème arrive dans les mains des dev.
Le dev en charge du problème récupère un dump de la base de donnée du client et créer une bdd avec celle-ci pour "reproduire le problème". cela signifie que les dev ont accès aux informations stocké dans la bdd du client. (adresse, mdp, etc...)
Les mot de passe eux, sont hashé en MD5.
Après, on crée un script si il faut pour l’exécuté sur la vrai base du client et hop soucis réglé (je passe les détails de la note pour expliqué au client que c'était parce que y avait des donnée fantôme, et que l'entreprise nous demande de bien supprimer les dump, bdd créee, etc...)

La dernière me choc un peu car personnellement, je trouve ça aberrant d'utiliser les données personnel des clients d'autant que je sais très bien que l'on peut travailler sans avec un peu de discipline et de conception.
Je me demande même si des organismes comme la CNIL laisserait passé cela.


Comme je l'ai dit plus haut, il s'agit de ma première expérience professionnel (sans compter les stages).

Je souhaite donc avoir votre avis sur la façon de travailler de mon entreprise...
Quand je leur ai posé des questions sur, pourquoi cela, pourquoi comme ça.... les réponse que j'ai eu sont: "Parce que le dev qui a fait ça, au moment de le faire, à estimé que cela été nécessaire" et "L'application est vieille, beaucoup de dev sont passé, il faut être indulgent..."

Le patron ne semble pas non plus vouloir changé grand chose, apparemment, 2 dev sont passé avant moi et ont fait à peu près les même remarque que moi mais le patron n'a rien écouté...
La seul chose qui est en train de changé, c'est qu'un dev est chargé de remplace le XUL par du html, mais avec le même design dégueulasse.

[Invité]

Business as usual

C'est du très classique, rien de neuf à l'horizon.

Les mots de passe sont hashés, c'est déjà un gros effort, au moins tu n'as pas à voir les BlowJob69 ou Manon2007 suivant le sexe de l'utilisateur...

[Antjac]

C'est ce qu'ont appelle du Legacy...
Sur le fait d'avoir accès aux données de prod, c'est litigieux... Si c'est pour résoudre un problème ponctuel c'est entendable, si c'est une base de dev non anonymisé, beaucoup moins

[Invité]

Sur le fait d'avoir accès aux données de prod, c'est litigieux... Si c'est pour résoudre un problème ponctuel c'est entendable, si c'est une base de dev non anonymisé, beaucoup moins

lol !
Quand une banque t'envoie les coordonnées de ses gros clients pour résoudre un petit problème, c'est litigieux ou c'est une grosse faille de confidentialité

[xyvamylapp]

C'est ce qu'ont appelle du Legacy...
Sur le fait d'avoir accès aux données de prod, c'est litigieux... Si c'est pour résoudre un problème ponctuel c'est entendable, si c'est une base de dev non anonymisé, beaucoup moins

Ben c'est les données réel du client, non anonymisé et bien sur on connait le client.

[Antjac]

Tout dépend du secteur, il y a des choses plus confidentielles que d'autres...

[xyvamylapp]

Mouai.... perso, les donnée personnel, l'idéal, ça doit pas être visible, peut importe ce que c'est....

Après oui, y a des données plus sensible que d'autre
Mais j'estime que si un site ou une boite doit aller regardé mon adresse mail ou le nombre de post que j'ai mis, à même la base de donnée, pour savoir si il y a un problème dans le code, ben c'est qu'ils ont foiré un truc.

Les nom, prénom, adresse mail, adresse, phone. c'est des données perso. le laissé a la vue de n'importe qui, ça peut causer des problèmes, important ou pas.
Imaginons que je veuille porter atteintes a un client, un coup de clé USB ni vue ni connue.... (Bon si je me fait chopé, je prend la total certe... mais admettons que ça passe)

Je récupère les données, "Mail, phone, etc...." je peux faire ch*er les victimes comme je veux....
Le logiciel gère des familles avec leurs gosses => donc je peux éventuellement atteindre des mineurs
En plus le logiciel a un module de paiements.... j'ai pas vue le code pour cette partie mais si ils gère les paiements comme le reste du code.....

Après, je suis peut-être optimiste sur le fonctionnement d'une entreprise, après tout c'est ma première boite...
mais la sécurité et la conception sont des points important pour moi et moi l'entreprise, en plus du logiciel, vend une expertise en sécurité informatique....
je vous cache pas que j'étais déçu dès le 2ème jour...

Mais à vous écouté, la sécurité et la conception sont des points qui sont vraiment pas acquis dans toute les boites informatique française c'est cela?

[Nita65]

Après, je suis peut-être optimiste sur le fonctionnement d'une entreprise, après tout c'est ma première boite...

C'est ça.

Mais à vous écouté, la sécurité et la conception sont des points qui sont vraiment pas acquis dans toute les boites informatique française c'est cela?

Peu importe le pays, le secteur... le fossé entre la théorie et l'existant est toujours frappant, affolant, décourageant.. Une boîte est une boîte, il y a des boîtes en tous genres. La qualité coûte, la sécurité coûte, les arbitrages sont des choix de management. Tout dépend du management. Et comme le management est humain, il est aussi incohérent : tatillon sur certains trucs, laxiste sur d'autres, avec es priorités qui parfois nous échappent et sur lesquelles ils (le management) ne prennent pas la peine de communiquer.

Il te faut, je pense, plus de temps pour comprendre et assimiler les tenants et les aboutissants. On ne peut pas juger en un mois sur la base de principes théoriques (aussi justifiés soient-ils). Relaxe, observe. Je ne dis pas d'abandonner ton esprit critique - au contraire, mais de le replacer dans un contexte.

[Pyramidev]

Bonjour,

D'après ta description, ce logiciel, c'est effectivement de la grosse merde.
D'ailleurs, pour enfoncer le clou, dans le code du logiciel que tu décris, où en est la couverture par des tests unitaires ?
Hélas, en informatique de gestion, tu verras probablement plus souvent du code sale que du code propre. La discipline du développement logiciel est jeune et les décideurs n'ont pas encore compris que le manque de qualité coûte assez cher à moyen terme et extrêmement cher à long terme.

Personnellement, je te conseille de ne pas rester trop longtemps dans cette boîte, pour deux raisons :

• Les recruteurs discriminent beaucoup en fonction des technos sur le CV. Si ta boîte reste en retard à ce niveau, n'y reste pas trop longtemps, car tu auras du mal à en partir.
• Dans une autre boîte, si tu as de la chance, tu tomberas peut-être sur un poste où tu passeras plus de temps à écrire du nouveau code qu'à ajouter des patchs à l'arrache dans l'urgence sur des trucs bancals déjà existants. Alors, si tu écris du bon code, tu en tireras vite des bénéfices, car ce code sera flexible et n'aura presque pas de bogues.

[xyvamylapp]

Bonjour,
dans le code du logiciel que tu décris, où en est la couverture par des tests unitaires ?

Houla, il n'y à déjà pas la base (de mon point de vue), c'est à dire des schéma, des modèles de conception... alors des tests...
Je suis a peu près sur qu'eux même ne connaisse pas très bien leurs propre logiciel...
Alors, il n'y a pas que du mauvais... ils ont leur petit système pour débugger...

[fiftytwo]

Bonjour à tous,

Développeur depuis environ 1 mois dans une petite entreprise qui édite un logiciel de gestion (il s'agit d'ailleurs de ma première expérience professionnel), je me pose de sérieuse question quand à la manière de travailler de cette boite...

Bienvenue dans la vraie vie !!!!

Zéro documentation:

voila ce qui se passe quand ceux aux commandes n'ont pas les burnes ni les connaissances pour dire au devs de faire du code propre et de la doc

- Une base de donnée problématique?:

cest que cette BDD nest peu ou pas maintenue , et encore moins optimisee au fil des annees

La méthode de travail pour aider les clients:

sur un logiciel lambda open source gratuit utilise par kevin , 15 ans , cela ne pose pas de problemes mais en entreprise ca fait limite limite . Cest comme sassoir au pied dune montagne enneigee et lancer des batons de dynamite a son sommet

Mon travail, consiste surtout a réglé des soucis des clients, qui appelle car la liste des utilisateurs affiche 29/30 enregistrements ou bien a corrigé des "anomalies"

Tu est dev et tu fais du support applicatif ?? elle est ou justement lequipe support du produit ???

La seul chose qui est en train de changé, c'est qu'un dev est chargé de remplace le XUL par du html, mais avec le même design dégueulasse.

tu payes de la m3rde , donc en sortie tu auras .... de la m3rde

[xyvamylapp]

Tu est dev et tu fais du support applicatif ?? elle est ou justement lequipe support du produit ???

Résumé très brièvement:

- Le client appelle le support (qui n'a pas d'expérience en développement), ils essaient de régler le soucis. Si il apparait que le problème ne peut être résolu manuellement par l'utilisateur, un "ticket" est crée.
- Le ticket est vérifié par l'équivalent d'un chef de projet/lead developper puis si c'est vraiment un problème qui à l'air de nécessité un script, le ticket est assigné a un dev qui doit rechercher le problème et faire un script, ou non, pour contourner le problème.

Et j'insiste sur contourner car très clairement, aucun des script que j'ai fait, et qui ont été validé, ne corrige le problème. C'est d'ailleurs ce qui me gène car les problèmes sont évident...
Je pensais qu'une entreprise chercher à se faire de l'argent plus ou moins facilement, pas à se faire chier avec des pseudo problème... m'enfin, je rentre juste dans ce merveilleux monde qu'est le travail donc y encore pleins de merveille de ce genre à découvrir...

[Ekolamar]

Résumé très brièvement:

- Le client appelle le support (qui n'a pas d'expérience en développement), ils essaient de régler le soucis. Si il apparait que le problème ne peut être résolu manuellement par l'utilisateur, un "ticket" est crée.
- Le ticket est vérifié par l'équivalent d'un chef de projet/lead developper puis si c'est vraiment un problème qui à l'air de nécessité un script, le ticket est assigné a un dev qui doit rechercher le problème et faire un script, ou non, pour contourner le problème.

Et j'insiste sur contourner car très clairement, aucun des script que j'ai fait, et qui ont été validé, ne corrige le problème. C'est d'ailleurs ce qui me gène car les problèmes sont évident...
Je pensais qu'une entreprise chercher à se faire de l'argent plus ou moins facilement, pas à se faire chier avec des pseudo problème... m'enfin, je rentre juste dans ce merveilleux monde qu'est le travail donc y encore pleins de merveille de ce genre à découvrir...

Tu as déjà ta réponse au-dessus : La qualité coûte cher.

Ca coûte moins cher de "patcher à l'arrache" par un ptit jeune sorti d'école que de refondre totalement l'applicatif (en gros, faudrait tout réécrire) car il y a trop de dette technique pour espérer transformer.

En plus du coût exorbitant de recréer l'application from sratch (une équipe dédiée en plus de l'équipe existante qui doit continuer à maintenir la vieille version), la boite va devoir vendre une "V2", certes plus propre/efficace avec moins de bug mais aussi probablement moins de fonctionnalités (qui seront rajouté au fur et à mesure), ce qui rend la vente difficile.

Pour avoir vécu cela avec des logiciels qui sont passé du "client lourd JAVA" bien moche/lent mais très complet à une super interface HTML5 full web, la perte en fonctionnalité est drastique et tu récupères vraiment au fur et à mesure le reste sur plusieurs années. Et le saut est souvent nécessaire par des éléments extérieur (en l’occurrence les failles de sécurité JAVA ou l'incompatibilité avec les OS récent, qui vont "forcer" les entreprises à changer, sinon on aurions encore le vieux client JAVA bien moche des années 90).

[Glutinus]

Hello,

Un éditeur de logiciels, c'est comme toutes les boites, elle doit se faire de la thune... et ça, au détriment de plein de choses !
J'ai intégré un (plutôt gros) éditeur il y a quelques années, en tant que presta. Miroité par "on va migrer le logiciel développé en XXX vieille techno toute pourrie en Java, et on fait venir les prestas pour ça". Finalement, java externalisé en Inde, et tout le monde reste sur la vieille techno pourrie. Par chance, j'ai bossé sur une autre appli, qui elle-même appelait 99% d'Oracle, donc j'ai monté en compétences sur Oracle.

Toi, t'as de la chance, tu reçois des tickets (pas la peine de mettre des guillemets, c'est le terme exact, sinon on dit "issue" mais en prenonçant à l'anglaise, "is-chiou"), des fois c'est le bordel et c'est à toi de t'organiser à coup de post-it et Excel...

Zero Doc : moi, je savais même pas où était installée l'appli quand je suis arrivé... Quand je suis parti 10 mois après, exténué, j'ai proposé de faire une doc pour mon remplaçant, qui plus est j'ai formé personne... Ma chef de projet voulait que je corrige encore des anos (et m'a refilé au passage une qui n'est pas dans mon périmètre et vieille... de 10 ans !), et quand j'ai envoyé mon mail d'Au-revoir à 16h, est venue me voir pour me dire pourquoi j'ai pas rédigé de doc et que je partais pas tant que je n'en avais pas fait
Chaque fois que tu proposes de faire la doc, les gens sont ravis... mais c'est à faire sur ton temps libre

Donc non, la doc, tu te la fais pour toi, surtout pour toi.

BDD : bah, bon information redondante, pas grave, ça bouffe juste de la mémoire... spoil, en décisionnel, on pré-calcule énormément d'information redondante, mais ça passe en process de nuit, et ça accélère les processus de reporting. Donc, pas grave quoi. Information manquante ? tant pis. Mais si y a pas quelqu'un dédié à la vérification de la qualité de la donnée, tant pis pour ta boite...

Process client : bah, rien de choquant, on appelle ça du support niveau 1 (genre, "vous avez pensé à appuyer sur F1 pour avoir de l'aide ?"), et 99% des anomalies passent en support 2, c'est-à-dire toi... Soit heureux que les utilisateurs aient pas ton numéro de téléphone ! Et sinon, y a 10, 20 ans, la sensibilisation de la donnée en production, c'était juste "faites attention", en soit t'avais accès à tout..., aujourd'hui avec CNIL et GDPR, beaucoup de boites sont dans la merde car doivent revoir les process.
Spoil : peu de clients / employeurs sont GDPR-compliant aujourd'hui, et on fait appel à des DPO, ce qui fournit une vague d'incompétents de société de consulting qui savent rien faire d'autres que répéter ce que disent les clients...
Chez un ancien client, une grosse banque, on m'a coupé l'accès en production du jour en lendemain. Normal, me diras-tu, sauf que je recevais encore des coups de fil "oui je comprends pas je suis censé voir 100.000 € sur le compte de Mr Paul Dupont" "Oui, je veux bien te croire "
Moi c'était régulier que je reçoive des dumps des clients, au moins tu peux reproduire l'ano, rien de pire que n'avoir aucune info que "ça marche paaaaaaas" mais derrière on peut rien te fournir. J'ai déjà vu des traitements qui faisaient des rapprochements directement sur des noms... va savoir si c'est une question d'encodage, de retour chariot caché, de signes diacritiques, de majuscule... si le client ne peut te fournir d'info.

[fiftytwo]

, aujourd'hui avec CNIL et GDPR, beaucoup de boites sont dans la merde car doivent revoir les process.

Ohh , mon sujet prefere !!! je confirme a 10000% !!

Le texte est sorti en 2016 , les entreprise ont eu 2 ans pour se preparer , mais les offres demploi pour les dpo ont commence a fleurir debut 2018 car les boites ont commence a s'inquieter vers fin 2017 .... au final presque personne n'etait pret et plein de changements on ete fait a l'arrache

Spoil : peu de clients / employeurs sont GDPR-compliant aujourd'hui, et on fait appel à des DPO, ce qui fournit une vague d'incompétents de société de consulting qui savent rien faire d'autres que répéter ce que disent les clients...

Amen ! Vis ma vie de consultant junior !

manager = hey fifty two , je tentendais parler de gdpr , tu t'y connais ?
fiftytwo = ouais jai lu des bouquins la dessus et je veux passer une certif a ce sujet
manager = bon on a un client qui nous veut pour du GDPR sur un projet cloud , donc on montes une equipe , tu vas y aller et apporter ton expertise (traduction = tes le seul mec qui sy connaisse et dont le TJM soit bas pour maximiser les benefs)
fiftytwo = heu , je t'ai dit que j'ai lu des livres ....
manager = pas de soucis , tu va etre accompagne d'un expert senior (qui n'y connaissait pas plus que moi) et ca va passer

Cest exactement ce que jai fait ! Une mission de 2 semaines ou on devait aider un client a faire l'etat des lieux sur un nouveau projet , sauf que celui ci etait dans les cartons depuis automne 2017 et jai debarque au debut du m4rdier en .... Janvier 2018.

[gangsoleil]

Bonjour,

Beaucoup de choses ici...

1/ Quelques informations seraient utiles :
- Quelle est la taille approximative de l'entreprise
- quel est le nombre de développeurs sur ce logiciel
- nombre approximatif de lignes de code

2/ Oui, une grosse partie de tes réflexions sont dûes à un manque d'expérience
- Pour la bdd, rien de neuf : elle a été créée comme ça vers la fin des années 90, par une ou plusieurs personnes formées (très probablement) sur le tas/tard, c'est à dire sans réelle formation de base de donnée.
- Pour la maintenance, le fait de faire des correctifs sur les données est une manière de fonctionner qui n'est, malheureusement, pas pérenne. MAIS, il est impensable de ré-écrire tout le logiciel en une fois, et je pense qu'il faudrait le modifier par bout.

C'est d'ailleurs une des choses qui pourrait être possible pour toi : proposer des améliorations, suffisamment petites, qui réduiraient les coûts de maintenance de manière drastique : mais tu ne pourras pas faire cela seul, il te faut le soutient d'un chef, de quelqu'un qui sera écouté et qui saura calculer et mettre en avant le ROI.

3/ Non, le mode de fonctionnement de la copie des BDD n'est pas en ligne avec le RGPD, principalement parce que les clients ne le sont pas. Pour faire court, oui, il est possible pour un client d'exporter sa base pour vous l'envoyer, mais vous devez avoir un accord signé avec le client montrant que votre niveau de sécurité est au moins aussi élevé que celui du client --> c'est peut-être le cas, ou peut-être pas, mais surtout les données personnelles non protégées ne sont pas en accord avec le RGPD -- et d'ailleurs il semble probable que le client ne limite pas assez les données collectées.

4/ Tu as 2 possibilités (enfin non, tu en as plein, mais j'en vois 2 intéressantes) :
- tu vas voir ailleurs, mais il te faudra expliquer à ton nouvel employeur pourquoi tu pars après si peu de temps ; et attention, l'herbe a exactement la même couleur ailleurs.
- tu te sens de corriger les choses. Attention, ça va prendre très longtemps, et il va falloir prévoir la migration des données client. Personnellement, ce n'est pas quelque chose que je confierai à un débutant sans qu'il soit supervisé par une personne ayant au moins 5 ou 10 ans d'expérience (je sais, la fourchette est large), afin qu'il puisse t'aiguiller sur les murs que tu vas prendre.

[xyvamylapp]

- Quelle est la taille approximative de l'entreprise
- quel est le nombre de développeurs sur ce logiciel
- nombre approximatif de lignes de code

- Environ 20 personnes, c'est une PME et oui, je me doute qu'elle à pas les même moyen qu'une grosse entreprise.
- Environ 5 en comptant le lead et le travail principal consiste à résoudre des incidents (Un enregistrement qui apparait pas, ce genre de chose).
- Beaucoup..... Le logiciel est vieux.

Donc certe, c'est une petite entreprise, beaucoup de dev sont passé dessus et elle à de faible moyen, cependant, et c'est peut-être du a mon inexpérience pro,
mais prendre un papier et un crayon demande pas énormément de ressource.
C'est ça que j'ai du mal à accepter, tous les jours, les clients appellent surtout pour se plaindre de problème comme ceux citer plus haut, et personne ne sait précisément d’où ça vient justement car personne ne connait assez bien le logiciel et personne n'a de support sur lequel s'appuyer mise à part quelque commentaire par-ci par la... ça et la fonction rechercher de l'IDE, gloire à lui.

2/ Oui, une grosse partie de tes réflexions sont dues à un manque d'expérience
- Pour la bdd, rien de neuf : elle a été créée comme ça vers la fin des années 90, par une ou plusieurs personnes formées (très probablement) sur le tas/tard, c'est à dire sans réelle formation de base de donnée.
- Pour la maintenance, le fait de faire des correctifs sur les données est une manière de fonctionner qui n'est, malheureusement, pas pérenne. MAIS, il est impensable de ré-écrire tout le logiciel en une fois, et je pense qu'il faudrait le modifier par bout.

Donc, j'ai compris, mon manque d'expérience me fait défaut, le monde du travail n'est pas un monde de bisounours et la logique passe après beaucoup de chose... ok, c'est compris!!!

Je me doute également qu'on va pas ré-écrire le logiciel d'un claquement de doigt, encore moins en une fois.
Mais, tous les problèmes que j'ai eu avait la même source. Le logiciel est vieux, mal conçu à plusieurs endroit. je doute que le modifier petit à petit soit une bonne idée car les fondations même du projet sont mal faites par endroit.

3/ Non, le mode de fonctionnement de la copie des BDD n'est pas en ligne avec le RGPD, principalement parce que les clients ne le sont pas. Pour faire court, oui, il est possible pour un client d'exporter sa base pour vous l'envoyer, mais vous devez avoir un accord signé avec le client montrant que votre niveau de sécurité est au moins aussi élevé que celui du client --> c'est peut-être le cas, ou peut-être pas, mais surtout les données personnelles non protégées ne sont pas en accord avec le RGPD -- et d'ailleurs il semble probable que le client ne limite pas assez les données collectées.

Je vois...
Mais concrètement, la seule "sécurité" se résume à: Quand vous avez fini, supprimer la copie, on veut pas que ça reste sur la machine et au contrat que j'ai signé.
Comme je l'ai expliqué plus au, rien n’empêche un dev de récupérer un dump sur une clé ni vue ni connue... j'appelle pas ça de la sécurité.

Ce serais un cas exceptionnel que de devoir corriger directement sur la base du client... pourquoi, pas, on est pas infaillible.
Mais la c'est banal. En plus à vous lire, c'est banal ailleurs aussi... Des organismes tel que la CNIL laisserait passer ce genre de chose?

4/ Tu as 2 possibilités (enfin non, tu en as plein, mais j'en vois 2 intéressantes) :
- tu vas voir ailleurs, mais il te faudra expliquer à ton nouvel employeur pourquoi tu pars après si peu de temps ; et attention, l'herbe a exactement la même couleur ailleurs.
- tu te sens de corriger les choses. Attention, ça va prendre très longtemps, et il va falloir prévoir la migration des données client. Personnellement, ce n'est pas quelque chose que je confierai à un débutant sans qu'il soit supervisé par une personne ayant au moins 5 ou 10 ans d'expérience (je sais, la fourchette est large), afin qu'il puisse t'aiguiller sur les murs que tu vas prendre.

- Est-ce que je peux, au minimum, espérer que l'herbe est mieux entretenu dans une entreprise plus grande?
J'en connait une de part une formation mais humainement elle laisse à désirer (Laisser moi deviner... C'est pareil pour toutes les grosses entreprises hein?).

- Oui, je me sens pas capable de le faire tous seul non plus sans supervision. Mais je sais que 2 autre dev que je remplace sont parti parce qu'ils ont proposé des choses... mais c'est pas passé et sont parti....
Alors, je tenterai ma chance, je proposerai des choses, je pointerai des problèmes... mais je sens que ça passera pas. Mais ça c'est une autre histoire...

[gangsoleil]

Bon, maintenant que j'ai bien noirci le tableau, voici d'autres points plus positifs (ou moins négatifs, à l'appréciation de chacun).

1/ Pour le côté pourri du logiciel : j'ai travaillé sur 2 projets similaires à ce que tu décris : 20 ans d'historique, une équipe de quelques personnes dessus, et un petit million de lignes de code réelles. Mais dans les 2 cas, il y avait une vraie volonté de trouver les sources des problèmes, car les décideurs avaient bien compris que passer 5 jours à corriger un bug coûte moins cher que de passer 1 journée chez 10 (ou 50) clients pour corriger leur jeu de données.
Dans les 2 cas, il y avait aussi, parfois, la possibilité d'améliorer des choses, de refactoriser, etc.... C'est lent, mais ça se fait.

2/ Pour la sécurité
Non, je n'ai jamais vu ça ailleurs. Ou du moins pas autant. Oui, il m'est arrivé d'avoir des données client non-sensibles entre les mains (c'est à dire des données que j'aurai sûrement pu finir par trouver via un autre biais), mais en aucun cas des données personnelles.
Et non, ce n'est pas acceptable. On est clairement ici dans le cas d'une violation manifeste du RGPD, c'est à dire que les efforts nécessaire pour sécuriser les informations ne sont même pas mis en place.

3/ Oui, l'herbe semble tout de même mieux entretenue dans d'autres entreprises. Tu peux tester le marché, voir comment ta candidature se présente.

[Nita65]

mais prendre un papier et un crayon demande pas énormément de ressource.

Si : du temps de travail. Ce qui coûte, sans exagération aucune, une fortune.

Mais, tous les problèmes que j'ai eu avait la même source. Le logiciel est vieux, mal conçu à plusieurs endroit. je doute que le modifier petit à petit soit une bonne idée car les fondations même du projet sont mal faites par endroit.

Tout dépend si ces anomalies sont critiques et à quel point le logiciel est mal fichu. Si ça fait 20 ans que des clients l'achètent et l'utilisent, c'est qu'il n'est peut-être pas si nul que ça ? Le monde du logiciel est quand même très concurrentiel, des boîtes naissent et meurent chaque jour, on peut donc supposer que ta boîte ne fait pas que de la m*rde (même si je me doute que la corrélation n'est pas forcément aussi directe). C'est un peu comme si quelqu'un se fiait à ton orthographe et en concluait que toute ta formation est à refaire (et pardon pour cette analogie pas très sympa pour ton orthographe, mais je ne trouve pas d'exemple plus approprié). Ca n'empêche pas de te comprendre, donc bon...

Des organismes tel que la CNIL laisserait passer ce genre de chose?

Non, évidemment, mais la CNIL n'a pas les yeux partout. Pas plus que l'inspection du travail, ou un tas d'autres choses. Combien vois-tu quotidiennement d'infractions au Code de la Route que les flics ne laisseraient pas passer... s'ils étaient là ? Pourtant les incidents restent rares (relativement au trafic, même si un accident c'est toujours un de trop).

Comparé à une sorte d' "idéal" de standards de qualité, 95% des entreprises font de la m*rde, ce qui ne les empêche pas de faire du chiffre, avec, globalement, des produits et des services que les clients apprécient. Et si on parle de conformité juridique, je me permets d'affirmer que 100% des entreprises (et des administrations, d'ailleurs) sont hors des clous sur un sujet ou un autre. (Pour un tas de raisons, dont la pléthore d'obligations et leur nature souvent contradictoire).

Donc on ne te dit pas que tu te crois chez les bisounours, mais simplement que ce qui te semblerait "normal" en termes de qualité, avec ton bon sens commun, est en réalité un idéal (à poursuivre, certes, mais inatteignable par nature). Et on a, je pense, tous été confrontés à ça dans notre premier ou nos premiers jobs, peu importe la branche et l'époque.

L'herbe sera-t-elle plus verte ailleurs ? Nul ne peut le dire - et toi probablement non plus.
J'ai plutôt envie de te demander si ça te plaît ou si ça te pèse de te projeter dans ce job / poste pour quelques années. Pas seulement en fonction de tous ces défauts, mais aussi en fonction d'autres critères (ambiance de travail ? autonomie ? est-ce qu'on te laisse être un peu créatif ? etc. ) et de voir en fonction de ta réponse. Enfin, c'est surtout à toi-même qu'il faut répondre, nous, je dirais, ça ne nous regarde pas :-)