Fansat, la facon de travailler que tu décris n'est pas morte, regarde du côté de l'embarqué (microcontroleurs hein, pas des cortex A-12)
Je pense que la facon de développer en assemblant des briques dont tu parles ne date pas d'hier. Quand j'ai commencé à coder il y a ~15 ans, c'était déjà le cas avec Java et Maven, et maintenant c'est surtout dans le dev Web qu'on voit ce genre de choses, à tel point que le quidam lambda revient aux applications natives car "l'internet, c'est lent".
C'est selon moi surtout une question de management qui a mené à ce genre de pratiques : les project managers ont une pression de vélocité et de coût importante, et sortent pour la grande majorité d'écoles de management dans lesquelles on apprend beaucoup de choses, certes, mais pas la technique (ni même les bases de la culture scientifique, dans mon expérience).
Donc il faut SCRUM, Jira et que les développeurs fassent des petits tickets. Si le Kanban ne montre pas un indicateur de vélocité pour l'équipe au plus haut, on ne cherche pas à comprendre quel problème était dur à résoudre, on va assigner "le ticket" à "une ressource" d'une autre équipe pour que ca aille plus vite.
On sépare les équipes responsables de la sécurité applicative et de la protection des données des équipes de dev, car elles ont des objectifs fixés par leurs hiérarchies diamétralement opposées (l'une doit aller vite pour qu'on puisse vendre, l'autre est une assurance sur le long terme).
J'ai vu des mecs satellisés d'équipes de WebDev (un métier avec ses nombreux problèmes, certes, mais dans lequel je ne suis qu'amateur) pour tenter de faire de l'embarqué car il fallait "une ressource en plus".
Je bossais avec l'un d'entre eux, j'ai passé plus d'un mois à tenter de lui faire comprendre que pour piloter des groupes froids de plusieurs centaines de kW, on avait besoin que le code soit robuste, et qu'on pouvait pas dire à l'utilisateur (quel utilisateur?) qu'il fallait "vider le cache et recharger la page".
Ce n'est que peu étonnant de voir le même management dire "si il faut 2-5x plus de serveurs pour contourner le bug, c'est pas grave, ca sera moins cher que de développer un fix".
Bref, pour moi, le souci dans "DSI" a toujours été le "D". Fin du HS
Pour en revenir au sujet (plus intéressant!), quand je bossais dans le datacenter il y a une bonne dizaine d'années, on estimait qu'environ 10% des serveurs allumés dans nos parcs étaient "oubliés" par nos clients. En creusant un peu chez un client, j'ai compris que ca fonctionnait comme cela :
- un sysadmin a besoin d'un (ou de plusieurs) serveurs, il en fait la demande.
- 6 mois plus tard, les achats se saisissent de la demandent et approuvent (note qu'ils n'ont souvent même pas à procurer le serveur eux-même, le sysadmin peut l'avoir de lui-même en deux clicks si on l'y autorise)
- l'OS pré-installé n'est pas le bon (trop récent), la boite impose soit RHEL 4 (!) soit une version exotique de windows 2000 (la "souche logicielle" approuvée). Il faut faire une demande spécifique à l'infrastructure provider car cet OS n'existe plus dans les images proposées, et d'ailleurs, fournir une licence pour ledit OS.
- retour aux achats, obtention d'une licence, envoi de la licence au fournisseur d'infrastructure, etc. etc.
- 8 à 10 mois après, le gars dispose de son serveur et peut commencer à y installer ses applis.
Bien évidemment, le sysadmin avait la pression pour rajouter un serveur de base de données ASAP et se fait taper dessus car il est 10 mois en retard.
Il commande donc un nombre de serveurs en avance pour en avoir sous le coude le vendredi soir à 7pm quand les alertes "server low on disk space" arrivent sur son téléphone, si il n'est pas parti de désespoir entre temps.
Le serveur reste dans le rack, touours allumé (quand j'éteignais les machines dont je n'avais pas besoin, les techs du datacenter les rallumaient lors de leur ronde de maintenance), à dissiper une centaine de watts à se tourner les pouces.
Un jour, le sysadmin part. Personne n'ose toucher à ces serveurs car "ils pourraient servir à quelque chose, mais je ne sais pas quoi". Trop risqué de l'éteindre.
Le fournisseur d'infrastructure n'a rien à gagner à inciter ses clients à les rendre : il réduirait son CA. De toute facon, même avec un paquet de serveurs qui se tournent les pouces, le client paye touours moitié moins (parfois 10x moins) que s'il était sur AWS, donc pas de risque de le perdre.
Ce post est déjà bien assez long pour que j'aborde le côté applicatif...