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.

http://www.developpez.com/public/ima...emaph-java.PNG

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.

http://www.developpez.com/public/ima...aph-nodejs.PNG

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.

http://www.developpez.com/public/ima...semaph-php.PNG

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.

http://www.developpez.com/public/ima...aph-python.PNG

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.

http://www.developpez.com/public/ima...emaph-ruby.PNG

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).

http://www.developpez.com/public/ima.../semaph-go.PNG

Source : Semaphore

Et vous ?

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

Voir aussi :

:fleche: En 2017, Python 2.7 est plus utilisé (63,7 %) que la version 3.x dans les projets commerciaux, selon Semaphore CI

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...

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).

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.

Citation:

---

Envoyé par Saverok

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.

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

Citation:

---

Envoyé par koyosama

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 :aie:
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.

Citation:

---

Envoyé par Saverok

Ç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

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

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 :aie:[/QUOTE]

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

Citation:

---

Envoyé par Saverok

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.

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.

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.

Citation:

---

Envoyé par clementmarcotte

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

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.

Citation:

---

Envoyé par Derek Corgan

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

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).

C'est une Sémaphore ? :ptdr:

Citation:

---

Envoyé par Saverok

Ç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

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.

Citation:

---

Envoyé par Marco46

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.

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

Envoyé par Saverok

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

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 :aie:

Citation:

---

Envoyé par Marco46

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.:mrgreen:

Citation:

---

Envoyé par Mat.M

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

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 :aie:

---

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

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.:mrgreen:

---

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.

Citation:

---

Envoyé par Marco46

(.../...)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.

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.