Bonjour,
 
Hier je tombe sur cet article de ZDNet (liés à d'autres plus anciens), intitulé "La DSI a-t-elle les compétences nécessaires à la transformation du SI ?".
 
Après sa (courte) lecture, je me demande si on assiste pas à un emballement pour les DevOps et l'ultra automatisé qui ressemble à ce stupide épisode (qui dure mais dont on revient peu à peu) pour le cloud il y a quelques années. Je dis stupide épisode car j'ai vu défiler toutes sortes de presta (même celui qui me vend les copieurs) pour me vendre du "Cloud" (bref, un serveur qui stocke mais données dans un datacenter ou du SaaS à des prix exhorbitants alors que ça tourne pour beaucoup moins cher sur nos serveurs en interne - backups et autres inclus -).
 
Donc voilà, ma question est de savoir comment vous voyez la chose ? Est-ce qu'il y a vraiment un changement radical ? A partir de quelle taille d'entreprise ça s'applique ? Et, finalement, en quoi y a t-il un changement radical ?
 
Merci.
 
 
 
 

Bof, c'est cyclique.
Dans l'IT (même professionnelle) il y a une forme de roulement entre les buzzwords (la virtualisation, le green IT, Agile, ITIL ,DevOps, le Cloud, le Serverless ...) inexorablement accompagné par des tripotées de sociétés voulant "surfer" (profiter ?) de la vague de business qui suit.
Ça génère pas mal de flou, d'escrocs, de fausses infos, d'idées reçues, etc ...

Ce qui est important c'est d'arriver à voir ce qui est pertinent et vraiment important au delà de la com'.

Non le cloud n'est pas fini (on est plutôt en plein dedans, en phase de consolidation).
Idem pour la conteneurisation, etc ...

Et c'est aussi pareil pour les méthodes de gestion de l'IT.
Les entreprises se transforment, les organisations aussi. Ça tire de nouvelles méthodes d'organisation et de management (ITIL, Agile, DevOps, ...).

Pour moi (pour avoir vécu les transformations de l'IT ces 15 dernières années et avoir bien trop de certification pseudo utiles) rien ne change fondamentalement à part la vitesse de changement : Tout s'accélère.
Une methode de gestion de l'IT montre peut-être plus rapidement ses limites aujourd'hui et de nouvelles méthodes apparaissent peut-être aussi plus vite.
C'est dans ce contexte que sont apparus Agile et DevOps qui se focalisent justement sur l'accélération des process.

En conclusion je pense qu'il peut être intéressant de rester à l'écoute de ce qui se fait de nouveau, en essayant de voir ce qui peut en être tiré.
Sachant que dans tous les cas les méthodes, l'écosystème, les outils, ... changent constament et de plus en plus rapidement.
Une entreprise ne peut plus se permettre de rester sur ses acquis pendant des 10aines d'années sans devoir payer un coût de plus en plus monstrueux le jour où elle devra évoluer.
De la même manière, tout n'est pas bon à prendre/transposer dans son contexte. C'est peut-être le point le plus important qui a fait que beaucoup d'initiatives Agile n'ont pas fonctionnées (on ne transpose pas le modèle Google/Netflix/Spotify/rayer-la-mention-inutile directement chez soi, car on n'est pas ces entreprises).

Merci pour ce retour.
 
Quand je parle de "stupide épisode" du cloud, c'est justement l'engouement démesurée pour une techno qui n'était pas du tout comprise. Bien évidemment, le cloud est maintenant très présent, même si la plupart du temps ce n'est pas du cloud. C'est plutôt l'avènement des liaisons très haut débit à des coûts raisonnables.
 
En fait, ça me rappelle le changement de rythme qu'il y a eu en dev web il y a ~10 ans avec les innombrables technos web, qui défilent à une vitesse dingue. Il n'y a que depuis 1 an que j'observe une accalmie.
 
Mais il n'empêche que lorsque je lis des articles comme ça, je me dis que je loupe vraiment quelque chose...

Les articles putaclics sont légions et ne représentent en rien la réalité et ne sont là que pour faire des vues sur un sujet "à la mode".

Si tu regardes bien toutes les "modes" précédentes, tu as eu ce même phénomène de "sur-hype" alimentée par au choix :
- ceux qui gravitent commercialement autour
- les geeks early adopters qui ont l'impression de changer le monde tous les 4 matins
- les journalistes qui s'engouffrent au milieu de tout ça

Il ne faut pas se laisser influencer par cette sur-hype, tout en essayant de voir quelles tendances se dessinent et ce qui peut être intéressant pour son contexte précis.
C'est ça, faire de la veille techno (ou autre d'ailleurs).

Si on prend par exemple le cas actuel de Docker :
Les concepts de conteneurisation existent depuis les début de la virtualisation matérielle introduite par les gros systèmes (IBM en tête) dès le milieu des années 60.
Docker est arrivé en 2013 et a juste démocratisé ces concepts en les rendant facilement accessibles et utilisables. Dès lors on a vu une grosse hype sur Docker qui s'essouffle un peu à cause des contraintes d'implémentation plus ou moins adatpées à un environnement de Production (même si ça évolue dans le bon sens).
Finalement on se rend compte que maintenant on parle plus de conteneurisation d'applications, de transformation et d'environnements de type Kubernetes que de Docker lui même, qui est pourtant sous-jacent à tout ça.
La hype autour de Docker était infondée ? Non, mais ce qui importe vraiment finalement pour un SI c'est d'avoir les outils pour mieux gérer ses applications et les conteneurs est une bonne approche.
Mais qui peut dire quand apparaitra la prochaine évolution qui changera encore la manière de faire et qui rendra peut-être obsolète les conteneurs ? (Le FaaS et le serverless par exemple ?)

Pour le cloud c'est encore pire car sont mélangés les visions grand public (dropbox, icloud, ...) et professionnel (AWS, Azure GCP, Alibiba Cloud, ..), ce qui n'aide pas la compréhension des enjeux.
Avoir la bonne vision IT du cloud et ne pas penser qu'on connait le cloud parce qu'on a un iPhone avec iCloud n'est pas si simple pour beaucoup de DSI.

Tout ça pour dire que pour s'en sortir il faut rester en veille constante, tout en gardant un regard critique (est-ce intéressant pour moi ? quels sont les gains potentiels réels ? dans quel sens va la consolidation du marché ? etc... ?)
Personnellement je me base sur pas mal de flux RSS, généralistes ou non, en fonction de mon domaine et de ce qui y est périphérique et je recoupe les infos.
Je ne saute pas sur une techno ou une méthode de-la-mort-qui-tue-et-qui-révolutionnera-même-ta-maman qui vient de sortir, mais je ne m'empèche pas d'aller jeter un coup d'oeil pour savoir de quoi ça parle.
Par contre, ça demande beaucoup de tri dans les sources et les articles qui passent.

Par exemple l'article que tu cites n'aurai pas beaucoup de poid pour moi :
- dès la première ligne ça dit clairement que l'article est sponsorisé (pour vendre quoi ?)
- le contenu n'apporte rien de plus que tout ce qui est publié sur les méthodes de transformation des SI depuis plusieurs années
- on ne dit pas "Digital", bordel ! C'est un anglicisme imposé par les marketeux et les journalistes faineants ou qui ne savent pas de quoi ils parlent (ou les deux...).

En tout cas c'est cette veille qui fera que tu auras moins de chance de "louper quelque chose".

Oui, j'ai appris depuis fort longtemps à élaguer au maximum (et c'est de pire en pire, avec des articles qui ont un titre alléchant - et encore, sans parler des putaclic - mais n'ont absoluement aucun contenu !). Mais cette peur de louper quelques chose, ce FOMO donc, est lié à ça : il n'y a guère de sources solides qui s'adressent aux RSI de PME.
 
Franchement, lire du publi-rédactionnel pour des produits MS ou IBM, ça te fait perdre toute confiance en ce que tu lis.
 
Donc c'est difficile, parce que je n'ai pas le temps d'analyser tout ce que je découvre.
 
Tu parles du serverless et du FaaS : qui a besoin de ça ? Est-ce applicable à une boite de 200 salariés (mon cas), de 2000 ? Pour quelles utilisations ? Où est-ce, comme je le vois pour le moment, réservé au web à fort traffic avec des besoins spécifiques ou un forme particulière de cloud computing qui pourrait donc s'adresser au marché du jeu vidéo et autres de ce type (3D) ?
 
J'ai aussi le problème de la pertinence de ces *aaS : où se trouve la frontière entre consommation idiote, sous-traitance voire manque de compétences ? Est-ce plus malin de sauvegarder en clair chez Amazon ou de se monter deux serveurs en HA chez online on l'on maitrise tout ?
 
Et puis KMS, ECR, Lambda, j'en passe : la formation d'un DSI c'est maintenant un recueil de marques ! Le boss de la boite d'info avec qui je bosse (ils sont quand même 50 techniciens et ingé IT) ne savait pas ce qu'était que WRM chez MS. Ok, ce n'est pas le truc le plus courant mais ne pas connaitre les fonctionnalités de l'OS qu'ils vendent et installent, alors qu'ils veulent me vendre leur pseudo cloud, c'est assez révélateur.
 
Bref, il (me) manque une revue pro qui dissèque tout ça, sans pression des annonceurs et avec une réelle expertise et un recul suffisant. Parce qu'il faut avoir 3 vies pour faire ça soi-même

Qui a besoin de ça ?  
Ben c'est comme toute techno, ça dépend.
Un boulanger n'en aura pas besoin, il n'aura besoin que d'une caisse enregistreuse et éventuellement d'un site web vitrine.
Une Fintech, une startup, ou une autre entreprise en aura au contraire peut-être besoin suivant ses projets et comment elle compte les implémenter.
Il n'y a aucune règle, que des besoins. De la même manière qu'un Active Directory n'est utile que dans une entreprise qui souhaite centraliser la gestion de son domaine et de ses utilisateurs.
 
Quant aux concepts de *aaS, rien ne change non plus. Ce ne sont que différents niveau d'abstraction pour rendre un service.
Une bonne manière de comprendre est l'analogie avec les pizzas et les différents degrés de service entre la pizza faite maison et le restaurant :

 
Peu importe le degré d'abstraction, il te faut les compétences pour comprendre comment ça fonctionne et comment s'en servir. Rien n'est magique.
Soit tu choisis de tout faire toi même chez toi (à l'ancienne), soit tu choisis de ne te concentrer que sur la valeur ajoutée que tu produis.
Par exemple, une banque en ligne offre des services bancaires au travers d'un site web et d'applications mobiles. Son métier ce n'est pas d'administrer des serveurs.
Une offre managée comme Amazon LightSail ou un équivalent peut faire l'affaire, et les équipes IT se concentrent donc sur l'applicatif, et non l'infra.
En plus ces offres sont accompagnées d'interfaces et d'outils moderne pour leur utilisation, leur monitoring, etc ... Le coté As A Service simplifie pas mal la gestion (et donc les coûts associés).
 

Des technos et des acronymes, il en existe depuis tout temps.
Ce ne sont que des produits, tout comme le sont Active Directory, MySQL, ou n'importe quel solution matérielle ou logicielle.
La veille sert justement à voir ce qui peut intéresser une entreprise suivant ses besoins.
 
Par exemple avant quand un DSI avait besoin de stocker des données en base, il devait connaitre/comparer Oracle, DB2, MySQL, Sybase, MSSQL, Informix. ...
Maintenant il y a aussi RDS, Aurora, Cloud SQL, MongoDB, Cassandra, etc ...
 
Surtout il y avait beaucoup de fournisseurs de solutions très ciblés (Oracle pour les bases, Microsoft pour les systèmes, etc ...).
Désormais avec l'approche As A Service, les fournisseurs étoffent leur offre pour couvrir un maximum de besoins. Par exemple Amazon Web Service et tous les services que tu as cité.
Mais tu n'as probablement pas besoin de tous ? En plus tu ne payes que ceux que tu utilises.
Alors il faut prendre ça comme un gros catalogue, dans lequel piocher, toujours suivant tes besoins.

Le problème vient justement de la grande diversité des offres.
Une seule source d'info, une seule revue ne peut pas balayer tous les sujets, toutes les technos, toutes les méthodos.
D'où l'importance de multiplier les sources pour pouvoir avoir beaucoup d'infos mais aussi de pouvoir les recouper entre elles et sentir les tendances.
Ensuite les offres gratuites permettent aussi de tester et de POC-er ces solutions.

nex84
merci pour ton analyse très pertinente.
j'adore le schéma des niveaux d'inforgerance de la pizza. Je prend

Quand je dis "Qui a besoin de ça ?", c'est une manière de dire que serverless et FaaS, ça ne va vraiment pas être utile pour grand monde. Mais je suis d'accord avec ton approche : tu pioches selon tes besoins, etc.
 
Seulement, ce que je disais et que je crains, c'est que l'offre (et parfois sa complexité) est telle que le boulot de DSI peut devenir une longue et pénible formation produits. Une expertise davantage - je ne dis pas "uniquement" - commerciale que technique.
 
Pourquoi pas. Sauf que dans ton tableau Pizza aaS, il manque deux critères primordiaux : le coût et le goût !
 
Certes ce n'est qu'une analogie (comparaison n'est pas raison, etc.) mais, pour en revenir à ma question initiale, est-ce que le DSI doit être expert en restau et choix de livreur de pizza ou être son propre pizzaïolo ?
N'est-on pas doucement en train de nous dire que le métier de DSI, c'est de docilement bien connaitre son catalogue (sans rien comprendre aux technos sous-jacentes) ?
 
 
 
 
 

Je me demande jusqu'a quel point le DSI doit être technique dans son travail pour gérer le SI. Il y'a tellement de techno de partout, que tout le monde ne peut pas tout connaitre, qu'elle est alors la part de travail/apport des équipes sous la responsabilité/direction du DSI ? Avec des avis et du bagage différent ?

Pour moi tout est une question de taille (si si).
La "taille" qui est importante peut être différente entre les entreprises (en nombre de personnes, en nombre de technos, en nombre de produits vendus, en nombre d'applications, etc ... etc ...). Il y a juste un moment où il devient impossible de tout savoir.
Un DSI d'une PME de 10 personnes offrant quelques services n'a pas forcément besoin de la même complexité d'architecture IT qu'un grand groupe internationnal.

Le premier peut connaitre sur le bout des doigts les outils et technos que sa boite utilise, ainsi que les solutions concurrentes existantes.
Le second par contre ne sera probablement qu'un "manager" avec éventuellement un verni technologique sur les tendances. Mais il ne connaitra jamais toutes les technos utilisées et devra se reposer sur ses équipes de sachants.
Tu peux aussi imaginer tous les échelons entre ces deux extrèmes.

Ensuite concernant mon schéma des pizzas, le cout et le gout sont des éléments annexes. Tu peux tout aussi bien trouver une excellente pizza pas cher au restaurant ou faite maison chez toi. L'inverse est aussi possible.
Mais ça ne change pas les offres possibles et leur niveau d'implication et de connaissances nécessaires.
Une fois ces offres décrites, c'est le moment du choix et seulement à ce moment là interviennent les critères subjectifs (prix, goût, qualité, etc ...).
Coté IT c'est pareil : c'est l'ensemble des critères qui comptent pour choisir l'offre (et le fournisseur qui va avec) qui sera la plus pertinente par rapport au besoin et aux contraintes.

Si on prend un exemple simple et concret : afficher une page web, tu peux :
- acheter ton serveur et le racker en datacenter, installer l'OS, le serveur web et mettre ta page, puis payer sa maintenance et son support, et gérer l'obsolescence à tous les niveaux
- prendre un VPS et ne t'occuper que du serveurs web et de la page web
- faire du CaaS sur une VM avec ton serveur et ta page web dans un conteneur Docker pour ne plus gérer le serveur
- prendre une offre SaaS wordpress (par exemple) et ne t'occuper que de la page web
- monter une fonction Python ou Go qui affiche la page en FaaS pour ne gérer que l'affichage de la page et ne payer uniquement le temps d'exécution par requête et plus le temps mort entre deux appels

Chaque niveau demande plus ou moins d'investissement en infra, en gestion, etc .... et ne coûte pas le même prix pour le run, ni ne nécessite les mêmes compétences.
Pourtant chacune de ces solutions peut être pertinente dans un certain contexte.
Tout dépend du ratio besoin/coût.
Sachant que le coût comprend l'implémentation, le "run", la maintenance, le support, la gestion de l'obsolescence et tous les moyens humains correspondants.
Coté besoin, on va trouver pour notre exemple la rapidité, la disponibilité, la scalabilité, etc ... auquel chaque niveau répondra plus ou moins.

Et pour répondre à la question de billy06 : le DSI doit "au moins" savoir qu'il a la possibilité de cuisiner sa pizza, ou de la commander, ou d'aller au resto.
Même s'il n'a pas à priori la recette de la pizza, il sait au moins ce que c'est et qu'il en veut une.

En fait, si ce que tu dis sur le web (que je pense maitriser plutôt bien) s'applique aux autres SI, il y a simplement plusieurs voies qui mènent à la solution. Plus tu es compétent, plus tu sauras prendre le chemin le moins couteux. Ça semble évident mais ça ne l'est pas tant que ça puisque bon nombre de projets web simples démarragent avec une charge (et plus tard une dette) technique disproportionnée.
 
Avant (sur le ton "c'était mieux avant" ), on faisait tout pour optimiser. Maintenant, on bourrine. A mon avis, l'expertise technique bas niveau s'est transformée peu à peu en expertise technique haut niveau. C'est ce qui m'inquiète, du moins parce que j'ai l'impression de ne voir que ça autour de moi (les RSI/DSI que je rencontre quand je me force à aller à des soirées, events, sont souvent mauvais techniquement mais connaissent dix fois plus de matériels et logiciels - commerciaux - que moi).
 
Mais je me trompe surement sur le devenir de ce métier qui, comme une multitude d'autres (notamment dans le BTP), se transforme pour faire de chacun des revendeurs/acheteurs. On te vend du rêve, on te vend du "ah mais oui, bien sûr que vous pouvez faire sans... c'est sûr.... enfin bon, c'est vous qui prenez le risque" (comme quelques malhonnêtes ont voulu me vendre le fait que tous les agissements internet des employés devaient être loggués pendant 1 an, en insistant lourdement).
 
Une chose que tu dis et qui m'interpelle : "Le second par contre ne sera probablement qu'un "manager"" ! Soit tu as parlé un peu vite, soit tu ne connais vraiment pas le management aussi bien que les SI Et, clairement, il y a en management autant bien plus de lacunes qu'en techniques informatiques.

Je ne pense pas qu'il y ait un "avant" et un "après".
Rien n'a vraiment changé, seul le rythme s'est accéléré.
Avant on pensait "amortissement" pour chaque choix ayant un coût (et surprise, tout à un coût : au moins en temps et en ressources) et les cycles étaient approximativement de 5 ans.
Maintenant, de nouvelles solutions apparaissent tous les 6 mois, voire pire et le marché se consolide lui aussi rapidement

Par exemple Docker a émergé en ~1 an avec pleins d'offres packagés (OpenShift, Rancher, Swarm ,..), puis quelques temps après le marché s'est consolidé très rapidement autour de Kubernetes.
Impossible donc d'anticiper avec certitude où va aller le marché et comment il sera dans 5 ans. Ce peut être inconfortable pour un décideur autant dans le choix en lui même que dans ses conséquences (investissement, maintenance, etc ...).
Ceux qui s'en sortent le mieux sont ceux qui arrivent à "agiliser" leur fonctionnement. À ce moment là choisir une solution a moins d'impact car on peut plus facilement changer en cours de route pour coller au mieux aux besoins et aux contraintes.

Bref, dans tous les cas il faut s'informer, se former, se renseigner, etc... autant que dans n'importe quel métier pour arriver à suivre tout ça et limiter les risques de se faire influencer par juste de belles plaquettes commerciales (si ce n'est de belles commerciales tout court, et j'en ai vu qui se sont fait avoir...).
Il faut vérifier, POC-er, valider que ça répond au besoin. Avoir l'esprit critique tout simplement.

Tu prend l'exemple du BTP et c'est un bon exemple car il y a beaucoup de parallèles avec l'IT (on construit des choses).
Un artisant doit savoir quels sont les nouveaux matériaux et les nouvelles techiques pour ne pas continuer à construire des maisons en torchi (et voir son business se limiter, voir mourir).
Comme dans tout domaine qui bouge et évolue vite en fait, il y a un coté très Darwiniste.

Concernant la dette technique (mais pas que) j'aime beaucoup cet article : https://blog.ippon.fr/2018/03/15/la [...] enouilles/
Il passe souvent très bien chez mes clients quand j'essaye de les sensibiliser au problème.

Par contre je suis entièrement d'accord avec toi concernant ce que tu appelles la "bourinisation" :
Malheureusement je pense qu'on est dans une période (dans l'IT) où on voit les effets de la mode de "l'ingénieur informaticien à tout prix". Le système éducatif a pondu des centaines d'écoles pondant elles mêmes des milliers de diplomés dans le domaine, sans trop se soucier de la pertinence des formations.
On a donc des armées de jeunes "informaticiens" vendus "prêts à l'emploi" sur le marché du travail.
Or ceux-ci sont souvent été formés à "pisser du code" et autres actions sans réelle valeur ajoutée par rapport à un niveau technicien. Ils ont malheureusement des compétences qui sont celles qui sont les plus offshore-isables.
Le problème avec ces profils c'est qu'ils ont justement tendance à ne proposer aucune réflexion dans leur gestion du travail et ne font donc que du travail bourrin à la chaine.
Combien de fois j'ai entendu ce genre de profil me sortir :
- on a pas le temps de faire bien = on a pas voulu prendre le temps
- oui mais on s'en fout, ça marche = je te balance ça sans savoir si c'est exploitable/maintenable/performant/sécurisé/...
- etc ...
Et le pire c'est qu'ensuite il faut dépenser un paquet de fric pour refaire quelque chose d'exploitable, ou simplement galérer à faire vivre un truc inmaintenable.
Sans compter sur la frustration à tous les étages sur la faible valeur créée, les bugs, les problèmes, le coût, les tâches répétitives, la non reconnaissance ou la sous-utilisation des compétences, etc ...
Pour moi ce n'est pas rentable à long terme, mais c'est difficile à montrer rendant la prise de conscience longue.

En fait j'ai tendance à voir l'IT au sens large sous deux aspects :
- Un aspect "industriel" dans son fonctionnement pour créer de la valeur (Taylorisme, Fordisme, Toyotisme, Agilité, etc ...)
- Un aspect "biologique", comme un être vivant, dans son fonctionnement interne ainsi que pour la maintenance de l'existant (santé, performance, maladies, vieillesse, etc ...)
Ça permet d'éviter au maximum ce que j'appelle le mode "catapulte" ("ça marche sur mon poste", "m'en fous c'est en prod", "c'est plus mon problème",  ...)

Comment tu conçois d'"agiliser" le fonctionnement ? Toutes les solutions que je vois impliquent de gros changements, des coûts importants, de la formation conséquente, etc. Je n'arrive pas à voir comment être agile : si tu as déjà des idées sur le sujet, je suis preneur.

Je n'ai pas parlé de coûts, mais toute transformation en a un.

Mon point est plus théorique : le but est d'être en capacité (intellectuelle, humaine, technique, ...) de changer plus rapidement.
C'est valable pour les méthodes de travail, l'organisation des services, les infratructures, les applications.
La méthode Agile (avec un grand A) est un outil possible, mais pas forcément le seul ni forcément le plus adapté. Mais ce n'est pas à ça que je faisais spécifiquement référence quand je parlais "d'agiliser".

Par exemple le grand sujet chez mon client actuel est le changement de politique d'Oracle sur le support de Java : le support devient plus limité dans le temps et il faut être capable de mettre à jour ~tous les 6 mois, contre plusieurs années auparavant.
Du coup il faut étudier comment fiabiliser et industrialiser la mise à disposition de nouvelles versions validées plus souvent, mais aussi revoir le cycle de livraison des applications et des tests pour prendre en compte ce changement, même sans livraison de valeur business.

Concernant la méthode Agile à proprement parler, il existe plusieurs frameworks qui guide son application (SCRUM, SAFe, ...).
Sachant que chaque framework ne sert que de guide et ne peut que rarement être appliquer tel quel et nécessite d'être adapté au contexte.
Il existe beaucoup d'infographies synthétiques permettant de comprendre les grandes lignes.
Par exemple on cite souvent le modèle Spotify (partie 1 : https://www.youtube.com/watch?v=4GK1NDTWbkY - partie 2 : https://www.youtube.com/watch?v=X3rGdmoTjDc).
Ce modèle est typiquement un bon modèle mais qui n'est pas appliquable partout tel quel. D'ailleurs, Spotify eux même ne l'appliquent plus (pas?) comme ça.

Ok, je connais SCRUM mais je n’avais pas imaginé ça applicable ici.
Je vais voir ce qu'ils en font (je n'ai jamais été ultra convaincu par ceux qui utilisaient SCRUM en dev mais bon, puisque c'est populaire...)
 
En tout cas, merci pour ces échanges et pour avoir passer du temps à répondre en détail.

SCRUM est orienté projets, du business au dev principalement.
À l'inverse, ITIL est plus pensé "Production/Exploitation".
C'est pour ça que la mode est au "DevOps" qui est une philosophie (et non une méthode ) qui prend un bout de SCRUM, de SAFe, d'ITIL et de Lean pour fiabiliser et accélérer les changements de bout en bout, de l'idée du business à sa réalisation en Production.

Le maître mot c'est "l'adaptation".
DevOps n'applique pas tout SCRUM ni tout ITIL par exemple car ces deux méthodes ont des aspects incompatibles (rapidité des changements vs. stabilité).
Par extension, un contexte organisationnel et humain ne sera pas "compatible" avec certains aspects.
Mais d'un autre coté rien n'empèche de prendre ce qu'il y a à prendre.