Discussion :

[abc.xyz]

Bonjour,
je poste ici une question qui va paraître évidente à beaucoup sans doute.
Dans la vie d'un site web, il arrive que un développeur qui n'est pas le développeur initial du site web reprenne le code en main pour le faire évoluer. Ce passage est t'il aussi évident en ce qui concerne les logiciels?Je veux dire lorsqu'une société quelconque décide de faire appel à un développeur pour lui coder un logiciel (et non pas à un produit logiciel fini qu'elle achète), est ce que cette société est tributaire de ce développeur?Ou alors cette société peut t'elle espérer que son logiciel pourra évoluer (un deuxième développeur prendra alors en main le code du développeur initial pour le faire évoluer) si le développeur initial qui l'a codé part à la retraite par ex?

merci et bonne semaine.

[escartefigue]

Bonjour,

La fabrication de tout produit, informatique, industriel et même culturel dans certains cas, est soumise à des changements dans les équipes.
L'entreprise doit s'organiser de sorte à ce que ces changements soient les plus indolores possibles, même si ça ne l'est jamais complètement.

[Pol63]

ca dépend à qui appartient le code source, rarement à un développeur, donc ca peut évoluer avec d'autres personnes, et sur les gros projets il n'y a pas qu'une personne qui développe

sinon je pense que c'est assez similaire, à savoir ca dépend du projet et des gens qui sont passés dessus

si tu dois modifier un module existant tu essayes de comprendre le code, et tu le modifies
si tu dois ajouter un nouveau module alors tu te branches sur le menu et tu code ton nouveau module en suivant (ou pas) le même genre de code que précédemment

parfois il y a des normes de langage ou des normes d'entreprise qui ont été suivis auquel cas c'est assez standardisé, donc lisible et modifiable facilement
parfois tu vas tomber sur du code qui n'a rien de suivi et ca peut être folklorique, comme un void de 2000 lignes sur un langage orienté objet (c'est du vécu ), on plusieurs méthodes de codage, et parfois même une ihm très différente d'un menu à l'autre (c'est du vécu aussi ^^)

[Glutinus]

Quand y a juste un quidam qui est parti, c'est dur, mais au moins il reste souvent des sachants qui peuvent dire comment le module a été implementé dans l'architecture globale... pour ma part j'ai déjà intégré, en tant que prestataire, un éditeur de logiciel A qui a racheté un produit chez un concurrent B... dès le rachat, tous ceux de B ont démissionné pour monter une nouvelle boite

Donc là je te dis pas la galère de non seulement comprendre le code qui a été pondu, mais aussi l'architecture et la manière dont le tout colle.

[abc.xyz]

Bonjour,
je vais étendre la question posée par ce post:
Lorsqu'une société A (dont l'activité n'a rien à voir avec l'informatique) décide qu'elle doit adopter une solution logicielle pour gérer ses affaires (des chantiers par ex dans le cas d'une société du bâtiment):doit t'elle plutôt faire appel à une société informatique qui vend des produits finis (logiciels de gestion d'affaire dans le cas d'une société du bâtiment) ou doit t'elle plutôt demander à une société de développeurs informatiques de lui coder selon ses besoins ce logiciel qui donc n'existe pas encore? Quels sont les avantages et inconvénients de chaque solution?

[Pol63]

pour quasi tous les besoins il y a au moins un soft qui existe, après ce n'est pas toujours évident de trouver la boite qui vend ce dont on a besoin
après un logiciel tout fait c'est à l'entreprise de s'adapter au logiciel
alors qu'un soft sur mesure c'est le soft qui s'adapte à l'entreprise
par contre le prix n'est pas forcément le même ...

à pondérer avec le fait que la plupart des softs standard sont quand même paramétrables pour essayer de s'adapter à certaines situations et/ou sont modifiables pour ajouter du sur mesure dedans facilement et rapidement

[escartefigue]

Ca dépend aussi du type de logiciel

C'est sans doute plus simple de trouver un logiciel de comptabilité générale qui satisfasse les besoins assez similaires d'une entreprise à l'autre, qu'un ERP dont la vocation est de couvrir la quasi totalité des pans applicatifs de l'entreprise et dont les différentes briques métier sont parfois (souvent) un assemblage de morceaux hétérogènes issus d'absorptions et fusions de différents logiciels à l'origine indépendants.
Sur la plaquette commerciale, ces produits sont parfaits, dans les faits c'est loin d'être le cas.

Attention à bien prototyper le fonctionnement avant de signer le bon de commande

Attention aussi aux incompréhension d'origine culturelle :
j'ai souvenir d'un logiciel de suivi des temps et des frais de mission, sous-traité à un prestataire cambodgien, le produit était une véritable catastrophe . Le prestataire n'avait absolument rien compris du besoin et pour cause, la notion de RTT, de frais de route, d'indemnité forfaitaire etc... pour un cambodgien c'est ... du chinois

J'ai souvenir également d'un ERP d'origine américaine installé chez un équipementier automobile européen, et dont la mise en place avait nécessité de lourdes modifications du code (heureusement que nous avions accès aux sources). De nombreuses fonctionnalités manquaient à l'appel car elles n'avaient pas usage outre atlantique
Sans compter que les performances étaient catastrophiques (d'un point de vue didactique, les requête étaient parfaites pour apprendre à des étudiants tout ce qu'il ne faut pas faire )