Pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter, inscrivez-vous gratuitement !

 

Affichage des résultats du sondage: À quel moment passez-vous à une nouvelle version d'un langage ?

Votants
21. Vous ne pouvez pas participer à ce sondage.
  • Quand la nouvelle version est supportée par les technologies que j'utilise

    8 38,10%
  • Quand j'estime que la nouvelle version intègre suffisamment de nouveautés intéressantes

    9 42,86%
  • Quand celle que j'utilise arrive ou approche sa fin de vie

    6 28,57%
  • Dès que la migration est plutôt facile à faire

    6 28,57%
  • J'ai une préférence pour les versions LTS

    5 23,81%
  • J'attends toujours les feedbacks des premiers utilisateurs pour me décider

    5 23,81%
  • Le choix m'est imposé en général par mon entreprise ou mes clients

    6 28,57%
  • Autre (à préciser)

    2 9,52%
  • Pas d'avis

    0 0%
Sondage à choix multiple
  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    2 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 012
    Points : 64 471
    Points
    64 471
    Billets dans le blog
    2

    Par défaut De nombreux nouveaux projets commerciaux sont développés dans des langages qui ne sont plus supportés

    Semaphore : de nombreux nouveaux projets commerciaux sont développés dans des langages qui ne sont plus supportés
    quelles en sont les raisons ?

    Semaphore CI est un fournisseur de solutions de Continous Integration & Delivery. Il est également connu pour ses publications régulières sur les versions de langages open source qui sont utilisées dans des projets commerciaux. Pour l’année 2017, Semaphore CI vient de publier une compilation de différents rapports qui montrent quelles versions des langages open source populaires comme Java, Go, Node.js, PHP, Python et Ruby sont utilisées dans les projets commerciaux, nouveaux ou existants. Les données sont basées sur des milliers de projets privés qui sont testés et déployés sur Semaphore.

    Le constat est que parmi ces projets commerciaux, nombreux sont développés dans des versions de langage qui ne sont plus prises en charge. La réalité diffère toutefois d’un langage à l’autre. Quel est le donc le constat pour chacun de ces langages et qu’est-ce qui pourrait expliquer cela ?

    Java

    Java 7 qui n’est plus supporté est encore utilisé par 17 % dans des projets commerciaux Java. La plupart des projets Java sont toutefois basés sur Java 8, ce qui est une bonne nouvelle puisque cette version est encore supportée. Par contre, Java 9 a été publié en septembre 2017, mais il semble qu'il ne verra aucune adoption significative parmi les projets existants. Oracle a annoncé que Java 8 sera une version LTS supportée jusqu'en 2022, tandis que Java 9 ne va pas bénéficier d'un support à long terme. Ceci, avec la nouvelle fonctionnalité de modularité qui demande un certain temps pour s'y habituer, est probablement ce qui pousse la plupart des équipes à attendre la prochaine version à long terme, Java 18.9 LTS qui devrait arriver en septembre 2018.


    Node.js

    Beaucoup de choses sont arrivées au runtime Node.js ces dernières années. Après avoir eu une adoption précoce, il a vu sa croissance ralentie, été forké, avant d'arriver enfin à une consolidation avec un nouveau calendrier de diffusion. En conséquence, la réalité est que près d'un tiers de tous les projets sont basés sur une version obsolète de Node, alors que moins de 10 % utilisent une version publiée en 2017 (v8 ou v9). Node 9 a été publié cet automne, mais Semaphore ne note pas encore d'adoption significative. Il est ici important de noter que c'est seulement depuis le mois de mars qu'AWS Lambda prend en charge la version 6.10 de Node.js alors que la version 0.10 de Node.js a été dépréciée fin avril. Cela peut-il expliquer en partie l'utilisation de versions Node.js non prises en charge dans les projets commerciaux.


    PHP

    PHP figure parmi les dix premiers langages les plus utilisés depuis des années, et il est présent côté serveur pour la majorité des sites accessibles aujourd'hui. La plupart des projets PHP (37 %) utilisent cependant la version 5.6, dont la période de support actif s'est terminée le 19 janvier 2017. Cette version continuera à recevoir des mises à jour de sécurité jusqu'à la fin de 2018. Les versions 5.3, 5.4 et 5.5, qui ne sont plus supportées, sont également utilisées dans 34 % des projets PHP. D'après Semaphore CI, cela peut être dû au fait que le processus de mise à jour de 5.x à 7.x est complexe. Par exemple, de nombreuses erreurs fatales ont été converties en exceptions, il y a beaucoup de changements dans la gestion des variables et des entiers, etc.

    La version 7.0 est utilisée dans 19 % de tous les projets PHP. Cette version a été publiée en décembre 2015, et sa période de support actif a également pris fin depuis le 3 décembre. Quant à la version 7.1 qui a été publiée en décembre 2016, jusqu'à présent seulement 9 % des projets PHP l'utilisent. PHP 7.2 ne figure pas encore dans les statistiques de Semaphore, ce qui est normal puisque cette version a été publiée il y a un mois seulement.


    Python

    Malgré la sortie de Python 3 en 2008, plus de 70 % des projets commerciaux étaient encore basés sur la version 2.7 l'année dernière. Cette année, les résultats sont un peu meilleurs pour Python 3, mais pas beaucoup. Il faut noter que le support de Python 2.7 est encore maintenu de manière exceptionnelle jusqu'en 2020, en raison des difficultés de migrer de la branche 2.x vers Python 3.x. Il y a aussi le support de Python 2.7 par des fournisseurs. C'est le cas par exemple d'AWS Lambda qui prend en charge Python 3.6 et 2.7 depuis le mois d'avril.


    Ruby

    Il faut noter ici que plus de 85 % des projets Ruby utilisent la version 2.0 ou une version supérieure. D'après Semaphore, dans l'ensemble, il semble que dès que les équipes passent de 1.9.3 à 2.x, il devient plus facile de passer à des versions plus récentes.

    Une chose importante à noter est que les versions 2.0 et 2.1 ont atteint leur fin de vie, ce qui fait que 33 % des projets Ruby utilisent des versions qui ne sont plus supportées. En outre, la fin de vie de Ruby 2.2 (utilisée dans 31,8 % des projets) est prévue pour le 31 mars 2018. Il est donc fortement recommandé de passer à des versions plus récentes, car les anciennes versions ne reçoivent aucune mise à jour de sécurité. Une autre chose que fait remarquer Semaphore ici est que Rails 5 ne supporte que Ruby 2.2.2 et les versions supérieures. Cela pourrait encore une fois indiquer que l'utilisation d'une version d'un langage dans les projets est en quelque sorte influencée par le support offert par les fournisseurs de technologie utilisant ce langage.


    Go

    La politique de publication de Go stipule que chaque version majeure de Go est supportée jusqu'à ce qu'il y ait deux nouvelles versions majeures. Ainsi, le graphique suivant montre que 60 % des projets Go commerciaux utilisent actuellement une version officiellement prise en charge (Go 1.7, 1.8 et 1.9).


    Source : Semaphore

    Et vous ?

    Que pensez-vous de ces statistiques ?
    Quand décidez-vous de passer à une version plus récente d'un langage ?
    Avez-vous encore des projets développés dans des langages qui ne sont plus supportés ?
    Si oui, de quels langages s'agit-il et pour quelles raisons ?

    Voir aussi :

    En 2017, Python 2.7 est plus utilisé (63,7 %) que la version 3.x dans les projets commerciaux, selon Semaphore CI
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éclairé
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    juin 2012
    Messages
    343
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : Finance

    Informations forums :
    Inscription : juin 2012
    Messages : 343
    Points : 718
    Points
    718

    Par défaut

    Ces stats reflètent pas mal ce que j'ai plus voir depuis quelques années

    Habituellement je teste la version la plus récente du langage assez tôt, cependant avant de l'utiliser dans un projet, je m'assure que la version du langage est bien supporté par les libraries, framework que j'utiliserais ainsi que l'environnement de développement.

    J'utilise encore java 8, car il y a encore trop de problème avec java 9 concernant spring, netbeans, spring boot...
    Aillez le courage de justifier vos -1.
    http://www.laboiteaprog.com/ - http://www.solutions-norenda.com/

  3. #3
    Membre expérimenté
    Profil pro
    undef
    Inscrit en
    février 2013
    Messages
    482
    Détails du profil
    Informations personnelles :
    Localisation : France, Lot (Midi Pyrénées)

    Informations professionnelles :
    Activité : undef

    Informations forums :
    Inscription : février 2013
    Messages : 482
    Points : 1 436
    Points
    1 436

    Par défaut

    Pourquoi ? D'une part par le manque de maîtrise pour le programmeur qui doit se taper la p'tite doc de 1000 pages (C++ toise les 1600 pages) en anglais qui accompagne chaque révision (les traductions arrivant une à deux années après... quand elles arrivent), Et d'autre part l’absence de recule quant à la fiabilité du nouveau bordel (c'est pas comme si l'industrie IT n'avait jamais connu de gros foirages lors de release/beta).

  4. #4
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 066
    Points : 7 485
    Points
    7 485

    Par défaut

    Je suis assez en phase avec @marc.collin
    Ce n'est pas parce qu'une nouvelle release du langage sort que l'ensemble de l'écosystème suit immédiatement (IDE, serveurs d'applications, frameworks, api, librairies, analyseurs de code, etc.).
    Faut attendre quelques semaines / mois pour que l'ensemble de l'écosystème de dev et d'exécution se mettent à niveau et se stabilisent.

    De plus, c'est vrai dans l'IT mais pas uniquement, il ne faut jamais se jeter immédiatement sur les nouveautés car y a forcément quelques bugs qui sont passés à la trappe lors des contrôles qualités (et rarement des petites choses).
    On peut être sûr qu'on va avoir au moins 1 à 5 patchs correctifs dans les 2 mois qui suivent la publication de la nouvelle release.
    Alors autant attendre un peu que ça se stabilise un peu.

    Pour finir, comme l'a très bien dit @23JFK, faut aussi que les développeurs se forment ou soient formés (pour les chanceux dont l'entreprise payent des formations).
    De même que les organismes de formations aient le temps de se mettre à jour...
    Ainsi que les éditeurs qui publient des livrent sur le sujet pour compléter / expliciter les releases notes officielles parfois obscures.

  5. #5
    Membre éprouvé
    Profil pro
    Inscrit en
    mai 2011
    Messages
    426
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2011
    Messages : 426
    Points : 910
    Points
    910

    Par défaut

    Citation Envoyé par Saverok Voir le message
    De plus, c'est vrai dans l'IT mais pas uniquement, il ne faut jamais se jeter immédiatement sur les nouveautés car y a forcément quelques bugs qui sont passés à la trappe lors des contrôles qualités (et rarement des petites choses).
    On peut être sûr qu'on va avoir au moins 1 à 5 patchs correctifs dans les 2 mois qui suivent la publication de la nouvelle release.
    Alors autant attendre un peu que ça se stabilise un peu.
    Tu peux eviter cela en testant sur des nouvelles environnement si tu as fais le découpage de ton application et suivant les principes de développement modernes (je dirais ricains car ils sont pas vraiment moderne). C'est l'avantage du container, changer de langage à la volée ou revenir en arrière sur tel environnement.

    Et si le projet est bien fait, tu dois avoir 4 niveaux de tests : test unitaires, test d'acceptance, test de performance et test de bout en bout. Et cela devrait couvrir les 70% de facteurs que tu as.
    Sans compter qu'avec un approache 12factors, changer de language c'est comme changer de chaussette. Bien sûre Java 9 a tout pété, mais tu peux t'appuyer sur tests unitaires pour faire la modification aussitôts. Même grahique cela a un impact minim. J'ai vu des équipe qui sont passé de telles languages à telles langauges sur dexu ans car ils ont découpé correctement leur coder.

    Si tu as fais cela, cela devrait enlever pas mal d'effort et un meilleur isolation, et tu peux contenir tes erreurs. Regarde comment les développeur wordpress font, c'est pas parfait c'est 40% de la perfection mais quand tu as un module ou thème qui merde, tu changes le module ou le thème.

    Même des connections spécifique pour un système d'exploitation, tu ne devrais pas avoir ce problème.

  6. #6
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    797
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 797
    Points : 2 900
    Points
    2 900

    Par défaut

    Moi j'aurais mis "plateformes/runtimes plus supportés" et pas "langages plus supportés". Dire qu'un langage n'est plus supporté n'a pas grand sens.

    La confusion est facile à faire en cette époque où même les créateurs font tout pour brouiller les cartes, mais la distinction est primordiale. L'écrasante majorité des versions de langage sont rétro compatibles. On casse rarement du code parce qu'on met à jour un runtime qui introduit une nouvelle version d'un langage. Au pire, des fonctions des bibliothèques de base (ou de bibliothèques tierces qu'on est obligé de mettre à jour) sont deprecated. On peut bénéficier de nouvelles primitives du langage qui sont introduites, mais on n'est jamais obligé de tout changer.

    Langage
    Bibliothèque
    Framework
    Runtime
    Plateforme

    Tous ces mots ont un sens, ce n'est pas pour qu'on les utilise à tort et à travers.

    PS : Node.js n'est pas un langage

  7. #7
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 066
    Points : 7 485
    Points
    7 485

    Par défaut

    Citation Envoyé par koyosama Voir le message
    Tu peux eviter cela en testant sur des nouvelles environnement si tu as fais le découpage de ton application et suivant les principes de développement modernes (je dirais ricains car ils sont pas vraiment moderne). C'est l'avantage du container, changer de langage à la volée ou revenir en arrière sur tel environnement.

    Et si le projet est bien fait, tu dois avoir 4 niveaux de tests : test unitaires, test d'acceptance, test de performance et test de bout en bout. Et cela devrait couvrir les 70% de facteurs que tu as.
    Sans compter qu'avec un approache 12factors, changer de language c'est comme changer de chaussette. Bien sûre Java 9 a tout pété, mais tu peux t'appuyer sur tests unitaires pour faire la modification aussitôts. Même grahique cela a un impact minim. J'ai vu des équipe qui sont passé de telles languages à telles langauges sur dexu ans car ils ont découpé correctement leur coder.
    Ça, c'est la théorie et elle est parfaitement valide dans le monde merveilleux de la théorie où tout est possible car on a le budget, les ressources, le planning et les clients / utilisateurs qui suivent tous ensemble en harmonie.

    Personnellement, en 12 ans de carrière pro, je ne l'ai jamais vu en place dans son intégralité.
    En général, on fait le minimum syndical de la démarche qualité et de l'intégration continue car on n'a ni le budget, ni le planning pour.

    Je viens tout juste de récupérer une application en plus à mon périmètre et je déprime sévère car il n'y a que 2 env. : la recette et la prod.
    Les développeurs travaillent en local mais connectés à la BDD de recette
    Mieux encore, il n'y a aucun flux qui tournent en recette donc on est obligé de faire un dump de prod vers la recette pour actualiser la BDD et conserver un jeu de données cohérents en recette...
    La misère totale.
    Des env. de travail pourri, j'en ai connu quelques uns mais là, on a franchi un nouveau palier.
    Le pire, c'est que je ne suis même pas dans une petite PME mais au sein d'un grand compte et que les autres applications dont j'ai la charge sont tout de même mieux lotis.

  8. #8
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 210
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 210
    Points : 22 825
    Points
    22 825

    Par défaut

    Citation Envoyé par Saverok Voir le message
    Ça, c'est la théorie et elle est parfaitement valide dans le monde merveilleux de la théorie où tout est possible car on a le budget, les ressources, le planning et les clients / utilisateurs qui suivent tous ensemble en harmonie.
    Et du ministère qui demande des délais délirants à nos clients, qui nous le répercutent, bien obligés. Et on se fait tancer par le grand chef américain parce-qu'on a pas respecté la procédure. Ben oui, si on prend le temps de la respecter, le client doit payer des centaines de milliers d'euros de pénalités au ministère. Et nous le répercute ensuite.

    Citation Envoyé par Saverok Voir le message
    Personnellement, en 12 ans de carrière pro, je ne l'ai jamais vu en place dans son intégralité.
    En général, on fait le minimum syndical de la démarche qualité et de l'intégration continue car on n'a ni le budget, ni le planning pour.
    Sans compter les résistants, hostiles à toute forme de structuration du travail, parce qu'ils ont peur d'être fliqués(à tort ou à raison, suivant les cas)

    Citation Envoyé par Saverok Voir le message
    Je viens tout juste de récupérer une application en plus à mon périmètre et je déprime sévère car il n'y a que 2 env. : la recette et la prod.
    Les développeurs travaillent en local mais connectés à la BDD de recette [/QUOTE]

    Oh, chochotte, tu ne fais même pas les tests en prod, et tu te plains? - bon, honnêtement, ça ne m'est pas arrivé souvent. Mais ça m'est arrivé.

    Citation Envoyé par Saverok Voir le message
    Mieux encore, il n'y a aucun flux qui tournent en recette donc on est obligé de faire un dump de prod vers la recette pour actualiser la BDD et conserver un jeu de données cohérents en recette...
    La misère totale.
    Oui, ça, c'est la misère. Après, ça dépend de l'appli. En hospitalier, il y a très peu de batches, et le peu qu'il y a peut être lancés au besoin depuis l'interface, donc ça ne me manque pas, ici. En bancaire, par contre, c'était la catastrophe.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  9. #9
    Expert éminent

    Homme Profil pro
    Développeur .NET
    Inscrit en
    janvier 2012
    Messages
    4 324
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2012
    Messages : 4 324
    Points : 8 995
    Points
    8 995
    Billets dans le blog
    23

    Par défaut

    Cela me rappelle l'historique "Bogue de l'an 2000", avec un tas de vieux programmes en COBOL fonctionnant avec des années codées sur deux chiffres, créés par des programmeurs qui voulaient sauver de l'espace mémoire rare et précieux. Les vieux programmes ont dû être corrigés dans l'urgence. Les programmeurs d'origine pensaient que leurs créations seraient tout simplement remplacées quelques années plus tard... Les remplacements ne se sont jamais produits. Les fonds disponibles allaient à la création de nouvelles applications et non au remplacement des applications existantes. On dirait que les leçons du passé sont trop vite oubliées

    Et actuellement, n'importe quel gestionnaire moindrement au courant de l'histoire du système Phénix doit avoir une peu bleue de tout remplacement radical d'un programme qui fonctionne même s'il est antédiluvien et mal foutu, par un nouveau programme. Cela n'aidera en rien au remplacement des antiquités.

    P.S. Là, j'ai mis le lien vers Radio-Canada, mais n'importe lequel média canadien (francophone ou anglophone) doit avoir son lot d'histoires d'horreurs de fonctionnaires avec pas de paye depuis une éternité ou des erreurs paye après paye.
    À ma connaissance, le seul personnage qui a été diagnostiqué comme étant allergique au mot effort. c'est Gaston Lagaffe.

    Ô Saint Excel, Grand Dieu de l'Inutile.

    Excel n'a jamais été, n'est pas et ne sera jamais un SGBD, c'est pour cela que Excel s'appelle Excel et ne s'appelle pas Access junior.

  10. #10
    Membre éclairé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    mai 2016
    Messages
    221
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 221
    Points : 797
    Points
    797

    Par défaut

    Pour le C++, je passerai directement du C++ 11 au 17, sans avoir installé de compilateur pour la version intermédiaire 14, dont les apports étaient assez mineurs.
    Par ailleurs, j'ai encore du code en C++ 98, qui a donc 20 ans, mais je ne réécris que lorsque cela apporte vraiment quelque chose au niveau des performances.
    => j'apprécie bien un langage préservant la compatibilité sur 15, 20 ans, et plus, j'ai autre chose à faire qu'à réécrire toutes mes librairies à chaque nouvelle version lorsqu'il n'y a pas de gains réels.

  11. #11
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    août 2009
    Messages
    344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations forums :
    Inscription : août 2009
    Messages : 344
    Points : 1 266
    Points
    1 266

    Par défaut

    Citation Envoyé par clementmarcotte Voir le message
    Cela me rappelle l'historique "Bogue de l'an 2000", avec un tas de vieux programmes en COBOL fonctionnant avec des années codées sur deux chiffres, créés par des programmeurs qui voulaient sauver de l'espace mémoire rare et précieux. Les vieux programmes ont dû être corrigés dans l'urgence. Les programmeurs d'origine pensaient que leurs créations seraient tout simplement remplacées quelques années plus tard... Les remplacements ne se sont jamais produits. Les fonds disponibles allaient à la création de nouvelles applications et non au remplacement des applications existantes. On dirait que les leçons du passé sont trop vite oubliées
    Les programmes développés (lorsqu'ils parviennent en production) ont une durée de vie nettement supérieure à celle estimée par leurs auteurs et je suis bien placé pour le savoir. De plus les auteurs n'assument que rarement la maintenance de leur bébé (car tâche non valorisée). Un bug peut survenir des années après le développement (car test mal effectué lors du développement initial).

    Citation Envoyé par clementmarcotte Voir le message
    Et actuellement, n'importe quel gestionnaire moindrement au courant de l'histoire du système Phénix doit avoir une peu bleue de tout remplacement radical d'un programme qui fonctionne même s'il est antédiluvien et mal foutu, par un nouveau programme. Cela n'aidera en rien au remplacement des antiquités.

    P.S. Là, j'ai mis le lien vers Radio-Canada, mais n'importe lequel média canadien (francophone ou anglophone) doit avoir son lot d'histoires d'horreurs de fonctionnaires avec pas de paye depuis une éternité ou des erreurs paye après paye.
    Louvois, Chorus.... en France nous ne sommes pas mauvais dans le domaine.

    Les mêmes causent produisant les mêmes effets.

  12. #12
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 066
    Points : 7 485
    Points
    7 485

    Par défaut

    Citation Envoyé par Derek Corgan Voir le message
    Les programmes développés (lorsqu'ils parviennent en production) ont une durée de vie nettement supérieure à celle estimée par leurs auteurs et je suis bien placé pour le savoir. De plus les auteurs n'assument que rarement la maintenance de leur bébé (car tâche non valorisée).
    Je ne suis pas d'accord avec le fait que les développeurs n'assument pas la maintenance de leurs programmes car il s'agit d'une tâche non valorisée car en général, les équipes de Projet et de RUN sont distinctes.
    En tant que Chef de projet et RA, j'impose une rotation entre la maintenance et le RUN, non pas par punition mais pour que chacun ait conscience des problématiques de chacun.
    De plus, les développeurs sont nettement plus en contact avec les utilisateurs côté maintenance et cela est souvent sources de nombreuses idées pour améliorer significativement (et souvent à moindre coût) l'utilisabilité, l'ergonomie et donc l'adhérence de la solution par les utilisateurs.
    Mais bon, cela demande une certaine organisation et beaucoup de mes collègues ne s'en donne pas la peine

    Ensuite, en France surtout, les développements sont essentiellement réalisés par des prestataires et donc, lorsqu'un bug est identifié des années plus tard, ce n'est pas que le dev ne veut pas s'en occuper mais c'est que bien souvent, il a tout simplement changé de mission (que ce soit pour la même entreprise ou ailleurs).
    Le tout, sans compter sur les évolutions professionnelles qui font que les personnes évoluent au sein de leur entreprise (et change d'équipe) ou d'entreprise (assez fréquent dans l'info en France).

    Bref, rien à voir avec le fait d'assumer ou pas ses bugs ou encore de juger cela ingrat.
    En tout cas, je ne l'ai jamais perçu ainsi.

    Citation Envoyé par Derek Corgan Voir le message
    Un bug peut survenir des années après le développement (car test mal effectué lors du développement initial).
    Je te trouve particulièrement sévère.
    Les causes peuvent être multiples (cas d'utilisation non prévu, évolution des librairies, etc.) et tout rejeter sur le développeur est simpliste et non justifié.
    Un développeur est rarement seul.
    Si il y a faute, elle est collective.
    Je ne pourrais jamais bosser dans une ambiance où lorsqu'un problème survient, le premier réflexe est de chercher un coupable sur qui rejeter la faute pour s'en laver les mains (que la personne soit encore présente dans l'équipe ou partie depuis longtemps).

  13. #13
    Membre du Club

    Homme Profil pro
    Inscrit en
    janvier 2008
    Messages
    34
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : janvier 2008
    Messages : 34
    Points : 57
    Points
    57
    Billets dans le blog
    1

    Par défaut

    C'est une Sémaphore ?

  14. #14
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    3 451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 3 451
    Points : 13 474
    Points
    13 474

    Par défaut

    Citation Envoyé par Saverok Voir le message
    Ça, c'est la théorie et elle est parfaitement valide dans le monde merveilleux de la théorie où tout est possible car on a le budget, les ressources, le planning et les clients / utilisateurs qui suivent tous ensemble en harmonie.
    Pour pas mal de boites ce n'est pas de la théorie c'est du réel. Des boites comme blablacar, doctolib, les-furets.com ont des pipeline de CI/CD qui permettent une mise en prod par jour voire plus du fait d'une stratégie de test appropriée. Je cite ces boites parce qu'elles se mettent en avant sur ces sujets dans des meetups / conférences ou via linkedin. Il doit y en avoir beaucoup d'autres.

    Ce n'est pas tellement une question de budget, c'est une question de compétence et de conscience des coûts. Le problème initial remonte au client qui n'évalue ses coûts qu'à très court terme, il veut une feature, on lui donne le nombre de J/H nécessaire au dev, il multiplie par le TJM et il a son coût. Or ce calcul est une vue de l'esprit. Le client croit avoir le coût mais il n'a qu'une vision biaisée et court-termiste. Il paiera 5 fois le prix en bout de ligne mais il ne s'en rendra jamais compte car le reste des coûts sera invisible par rapport à sa manière de compter.

    Une boite qui produit son propre service / logiciel / SI et qui maîtrise tout de bout en bout peut avoir cette vision. Ce n'est donc pas un hasard si les organisations qui s'adressent à des SS2I obtiennent de la merde, c'est normal elles achètent de la merde. Quand on achète un plat de lasagne à 2 euros 50 il ne faut pas s'étonner d'avoir de la viande de cheval à la place du bœuf.

    Et c'est essentiellement de la faute de ces organisations, les SS2I ne font que répondre à une demande.

    IMHO tout part de là. Les dirigeants de ces organisations sont incultes. Ils voudraient exister à l'ère de l'information sans informaticiens et c'est idiot.

    Citation Envoyé par Saverok Voir le message
    Personnellement, en 12 ans de carrière pro, je ne l'ai jamais vu en place dans son intégralité.
    En général, on fait le minimum syndical de la démarche qualité et de l'intégration continue car on n'a ni le budget, ni le planning pour.
    Moi en 12 ans j'ai déjà vu des trucs très propres dans des petites structures comme dans des grosses et des trucs ultra dégueux dans des petites comme dans des grosses. Et ce n'est jamais une question de budget, j'ai vu des budgets hallucinants engloutis pour produire une douzaine d'écrans juste parce que les décideurs sont des ignorants.

    Après c'est certain que c'est rarissime de voir du propre et bien fait quand on est presta, c'est par nature incompatible.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  15. #15
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 066
    Points : 7 485
    Points
    7 485

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    Pour pas mal de boites ce n'est pas de la théorie c'est du réel. Des boites comme blablacar, doctolib, les-furets.com ont des pipeline de CI/CD qui permettent une mise en prod par jour voire plus du fait d'une stratégie de test appropriée. Je cite ces boites parce qu'elles se mettent en avant sur ces sujets dans des meetups / conférences ou via linkedin. Il doit y en avoir beaucoup d'autres.
    Toutes les entreprises que tu cites sont des entreprises assez jeune (voir très jeune) qui ont été développé par et pour le web.
    Autrement dit, elles ont l'informatique dans leur ADN.
    Dans chacune de ces boîtes, tu as au moins un informaticien de métier qui fait parti du CODIR (si ce n'est pas l'un des fondateurs).

    Dans les boîtes par lesquelles je suis passé (en presta ou en interne), c'est totalement différent car, pour commencer, elles ont plus de 50 ans (157 ans pour mon entreprise actuelle).
    Bref, l'informatique n'est pas au coeurs de leur business d'origine.
    Même si aujourd'hui le web devient extrêmement important, les métiers ne le voient tjrs pas comme une ressource / moyen / levier pour générer du business.
    L'informatique n'est vu que comme un coût ou au mieux, comme un moyen de réduire les coûts tout en augmentant la productivité.
    Mais absolument pas comme un axe business.

    Du coup, normal que les investissements info soient effectués uniquement avec une vue court terme ce qui se paye cher par la suite et fait le beurre des SSII.

    Vue la jeunesse du web, je pense que les entreprises incultes en info (avec les conséquences que l'on connaît) sont bien plus nombreuses que celles qui s'en sont pleinement investies.

  16. #16
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    3 451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 3 451
    Points : 13 474
    Points
    13 474

    Par défaut

    Je suis d'accord avec tout ce que tu viens d'écrire. C'est parfaitement dans la continuité de ce que j'ai écrit. C'est le véritable problème, les dirigeants des entreprises / organisations bien installés sont des quinqua voire plus pour la plupart et ils sont encore dans les années 80. Et pire, certains ont été devs pendant quelques années dans leur début de carrière, ils ont été au mieux des développeurs juniors et ils ne comprennent rien à ce métier.

    Ces gens sont un danger pour leurs structures parce qu'ils ont un système de pensée qui n'est pas en phase avec le présent.

    Bref, l'informatique n'est pas au coeurs de leur business d'origine.
    C'est là que se situe l'erreur. L'informatique n'est pas un coeur de métier en soi, il est une composante vitale de tout coeur de métier qui traite de l'information. N'importe quelle administration, banque ou assurance est dans cette situation.

    Du coup, normal que les investissements info soient effectués uniquement avec une vue court terme ce qui se paye cher par la suite et fait le beurre des SSII.
    Ce qui m'inquiète c'est que les anglo-saxons ne raisonnent pas du tout comme ça. Ils ont parfaitement intégré le changement d'ère. J'ai l'impression qu'on est dans la même situation que lors de la révolution industrielle où les anglais ont effectué la transition beaucoup plus vite et beaucoup plus tôt que nous. Il semblerait que l'histoire se répète sauf que les USA ont le rôle de l'Angleterre et de son empire "où le soleil ne se couche jamais". Tous les services utilisés, toutes les données sont stockées chez les américains. C'est un énorme problème.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  17. #17
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 627
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 627
    Points : 13 591
    Points
    13 591

    Par défaut

    Citation Envoyé par Saverok Voir le message
    Du coup, normal que les investissements info soient effectués uniquement avec une vue court terme ce qui se paye cher par la suite et fait le beurre des SSII.
    mais non une vue à court terme n'est pas profitable aux SSII bien au contraire..
    les SSII ont intérêt à prendre la maitrise d'ouvrage de projets sur le long terme sinon ça ne leur rapporte rien.
    Si tu fais un projet de développement pour un client sur un ou deux mois ça n'a aucun intérêt économique et ce n'est pas rentable
    Citation Envoyé par Saverok Voir le message
    Vue la jeunesse du web, je pense que les entreprises incultes en info (avec les conséquences que l'on connaît) sont bien plus nombreuses que celles qui s'en sont pleinement investies.
    qu'une entreprise soit inculte ou pas ça n'a aucun sens , une entreprise existe pour faire de l'argent et du chiffre d'affaire ; pas pour accumuler des connaissances comme dans une classe de lycée
    Citation Envoyé par Marco46 Voir le message
    Ce qui m'inquiète c'est que les anglo-saxons ne raisonnent pas du tout comme ça.
    les anglo-saxons notamment les Américains tout ce qu'ils veulent c'est la course à la technologie comme ils avaient fait avec la course aux armements face aux Russes.
    Résultat les Russes en construisant des missiles n'ont pas pu tenir cette course, le peuple russe s'est totalement appauvri avec les dévaluations du rouble successives..

    maintenant avec la course à la technologie les entreprises françaises comme des benêts importent massivement de la technologie hardware d'Asie et software des USA en croyant que c'est ça qui va booster la croissance.
    Au lieu d'investir dans des secteurs industriels comme le font les Allemands.
    Mais ça c'est un autre sujet et je fais du HS

    Pour moi le numérique et l'informatique c'est une industrie "cheap" facilement délocalisable contrairement à l'industrie lourde.
    Et en rentrant dans un magasin de meubles, Protagoras se dit : "l'Homme est la juste mesure des chaises"

  18. #18
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    3 451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 3 451
    Points : 13 474
    Points
    13 474

    Par défaut

    Citation Envoyé par Mat.M Voir le message
    mais non une vue à court terme n'est pas profitable aux SSII bien au contraire..
    les SSII ont intérêt à prendre la maitrise d'ouvrage de projets sur le long terme sinon ça ne leur rapporte rien.
    Si tu fais un projet de développement pour un client sur un ou deux mois ça n'a aucun intérêt économique et ce n'est pas rentable
    Les SS2I ont intérêt à faire croire à leurs clients qu'ils peuvent sous-traiter leur informatique sans conséquences pour leur activité. Sarevok parlait de courte vue du point de vue du client de la SS2I qui lui raisonne à courte vue. Les achats drivent les budgets en ne regardant que le TJM proposé par les 3 ou 4 SS2I qu'ils ont référencé et en utilisant des contrats de 3 à 6 mois qu'ils renouvellent au fil de l'eau.

    Citation Envoyé par Mat.M Voir le message
    qu'une entreprise soit inculte ou pas ça n'a aucun sens , une entreprise existe pour faire de l'argent et du chiffre d'affaire ; pas pour accumuler des connaissances comme dans une classe de lycée
    Le fondement de toute l'activité d'une entreprise c'est son savoir-faire, c'est ça qui lui permet de créer de la valeur ajoutée. Donc si, ça a complètement du sens, une banque qui n'a pas compris que l'informatique fait parti de son savoir-faire c'est une banque ou une assurance qui est restée au XXème siècle. C'est une erreur stratégique fondamentale de penser que c'est sous-traitable.

    Citation Envoyé par Mat.M Voir le message
    maintenant avec la course à la technologie les entreprises françaises comme des benêts importent massivement de la technologie hardware d'Asie et software des USA en croyant que c'est ça qui va booster la croissance.
    Au lieu d'investir dans des secteurs industriels comme le font les Allemands.
    Mais ça c'est un autre sujet et je fais du HS

    Pour moi le numérique et l'informatique c'est une industrie "cheap" facilement délocalisable contrairement à l'industrie lourde.
    Le software comme tu dis n'est pas une industrie. Le hardware oui mais pas le software. Un processus industriel c'est la production en série d'un même item, la production d'un logiciel en série ça s'appelle un copier coller d'un binaire. Le plus important dans la création d'un logiciel c'est le personnel qui écrit ce logiciel. C'est là que se situe toute la valeur. Or sous-traiter une compétence c'est la perdre. C'est donc une erreur majeure de sous-traiter l'écriture de ses logiciels, c'est une perte de contrôle totale sur le processus, on est même plus en mesure de contrôler ce qui est livré puisqu'on a sous-traité la compétence.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  19. #19
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 210
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 210
    Points : 22 825
    Points
    22 825

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    (.../...)Le software comme tu dis n'est pas une industrie. Le hardware oui mais pas le software. Un processus industriel c'est la production en série d'un même item, la production d'un logiciel en série ça s'appelle un copier coller d'un binaire. Le plus important dans la création d'un logiciel c'est le personnel qui écrit ce logiciel. C'est là que se situe toute la valeur. Or sous-traiter une compétence c'est la perdre. C'est donc une erreur majeure de sous-traiter l'écriture de ses logiciels, c'est une perte de contrôle totale sur le processus, on est même plus en mesure de contrôler ce qui est livré puisqu'on a sous-traité la compétence.
    Avec une nuance : c'est une erreur si c'est ton cœur de métier. Si tu est un hôpital, c'est une erreur de faire toi même ton propre logiciel de gestion de la cafétéria. Mais si tu t'appelles Starbucks, c'est une erreur de ne pas le faire.

    Mais d'accord sur le principe : la production logicielle(qui inclut l'exploitation, pas seulement la duplication) n'est pas aussi difficile que la conception, spécialement si on compare à l'industrie. L'inverse est vrai aussi, cf les soucis de Elon Musk pour produire en masse la Tesla. Il n'a pas ce genre de problèmes avec ses fusées, les cadences sont suffisamment lentes. En automobile, essayer de passer de 300 voitures mois à 3000 a suffi à le planter pour un bon moment.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  20. #20
    Membre du Club Avatar de Dwalin_7
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2014
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juillet 2014
    Messages : 16
    Points : 43
    Points
    43

    Par défaut

    On attend un peu pour que les autres essuient les plâtres, puis on teste afin de valider que notre code existant fonctionne toujours, et que les nouveautés sont intéressantes.
    En général ça bloque sur un des deux points et c'est comme ça qu'on laisse passer les versions.

Discussions similaires

  1. Requete sur des champs qui ne sont pas dans une autre table
    Par jean christophe dans le forum Débuter
    Réponses: 4
    Dernier message: 20/05/2010, 18h05
  2. Réponses: 2
    Dernier message: 28/12/2007, 18h14
  3. obtenir des entrees qui ne sont pas dans une table
    Par firejocker dans le forum SQL Procédural
    Réponses: 7
    Dernier message: 26/12/2007, 23h07
  4. Réponses: 6
    Dernier message: 29/06/2007, 10h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo