Reprise du message précédent :
C'est ce que j'allais dire, comment tu veux faire un projet en deux mois max. C'est forcément des trucs bateaux

 
+1.
 
De plus avoir la chance d'être sur un projet from scratch qui n'a pas encore de run puisque pas en prod va faire automatiquement que tu vas être parmi les "sachant" donc forcément faire du run dès la mise en prod effective.  
Enfin le run c'est la vie.    
 

Ce que vous appelez "run" c'est le "support post-MEP" ? Et l'évolutif du SI post-MEP, vous l'incluez dedans ou pas ?
De ma compréhension :  
BUILD = projet avec objectif de MEP
RUN = support + projet post-MEP
Mais il y a souvent ambiguité dans les offres d'emploi, où les recruteurs font passer du "support" tout court pour du "RUN" sans partie "projet post-MEP". C'est le piège dans lequel je suis un peu tombé dernièrement.

Ça dépend des boites chez moi le projet/build, c'est bosser sur un truc pas en service (donc sans utilisateurs).
Le reste c'est du run, en gros.
Une MEP c'est du run si l'appli est déjà en service.

Après tu peux faire un projet par dessus une application en service, genre refonte infra ou traitement obsolescence. Mais du coup c'est un projet.

Le projet reste un mode de travail différent du run.

Je suis assez d'accord, à ceci près que je trouve la frontière floue entre le "run" et le "projet" dans ton exemple. Genre parmi les suivants, lequel est du "projet" en run et lequel ne l'est pas (aka du "support" ) sur une appli déjà en PRD :  
 
- Rajouter une fonctionnalité à un site (style un bouton "Delete My Account" )
- Modifier en profondeur un workflow existant pour que ça aille plus vite
- Automatiser des tests de non régression
- Adapter plusieurs fonctionnalités à un changement de loi
- Migrer les bases de l'appli dans le cloud
- Changement de techno / DB
- Développer une interface pour un nouveau système tiers
 
?
 

 
En réalité je pose surtout la question pour m'éclaircir la réponse à moi-même, parce que je me connais et je sais que j'adore le projet et que je déteste le support ! Mais pour moi la différence essentielle, c'est que le "projet", c'est quelque chose qui livré apporte une valeur ajoutée évidente au business (métier). Le support n'apporte pas de valeur ajoutée, mais aligne un système sur la valeur ajoutée espérée, ou apporte une valeur ajoutée transparente pour le métier. Enfin, c'est ma façon de voir les choses, mais je pense que beaucoup d'IT BA ont comme moi surtout envie de se faire flatter par le métier et se lassent rapidement d'une fonction qui consiste à repasser en éboueur sur le travail mal fait des personnes qui s'occupent des projets et qui piquent à tort tout le mérite si ça déborde au helpdesk, ou des tâches en sous-marin (du point de vue du métier) pour s'assurer que ça continue tout simplement de marcher comme d'habitude (évol technos, changement d'infra...etc.). Enfin, ce n'est que mon interprétation.

Une réponse simple : ça dépend totalement des entreprises.
Pour te dire, chez moi, on veut casser beaucoup plus la frontière entre projet et run, pour éviter de faire un process projet pour un truc qui peut se faire en run (process plus simple).
Donc quand il y a un doute, bah je tranche pour que ce soit le plus simple et le plus adapté.

Il est vrai que le max que j'essaie de faire, c'est projet = besoin business.
Par contre, pour toutes les releases applicatives, c'est du run de notre coté (on est la prod), car la MOE nous livre un package qu'on installe, sans plus. Peut être chez elle ça a été un projet, mais nous on a pas été embarqué dedans.

Il est vrai que certains préfèrent la partie build /projet, car tu construis des choses, c'est plus intéressant.
Mais j'en ai qui préfèrent le run/support, car plus dynamique, des imprévus, et beaucoup moins d'administratif que le projet.

Vous êtes sérieux à parler du build / run a l ere du CI/CD ?

 
Tu rigoles, mais dans ma COGIP ce sont toujours les ops qui appuient sur le bouton pour faire les mises en prod.  
Même en 2021, j'imagine que ne suis pas seul à être dans ce cas...

 
Je viens d'arriver dans le bancaire, le CI/CD c'est prévu pour 2032  

Je trollais j'avoue.

Oula, c'est la première fois que j'en entends parler, j'avoue...  Encore un truc à la mode qu'on va sortir dans tous les articles high tech et à toutes les sauces ?

Etre dans l'IT et ne pas connaitre le Ci/CD ca c'est du troll par contre.  

Bah c'est possible de pas connaitre le mot, c'est juste un énième buzz word.
Les concepts derrière existent depuis un bout de temps.

Buzz word?      

CI CD? C'est pas un buzz word.

+1

Disons que c'est pas au même niveau de buzzitude qu'Agile, Micro Services, ou Blockchain

Non mais le machin ça fait 15 ans que ça existe

Ça ne fait pas vendre de placer ça pour un profil tech.

Faut parler de serverless, micro frontend, cqrs, ddd  

 
Merci pour la découverte du ddd. Genius.        

+1, c'est généralisé, mais certaines livraisons, on fait juste un clic sur un bouton dans un portail.
On est l'OPS, on est responsable... alors qu'on sait rien du contenu.

Mais oui, bien sûr, le nombre de fois où je me suis fait recaler en entretien parce que je ne savais pas prononcer meuporg ou bien ce qu'est un XPTRLZ dans le langage obscur des intégrateurs aigris, franchement j'ai honte ! Faut juste rappeler qu'IT != Dev/DevOps/Prod/Intégration (qui d'ailleurs sont des fonctions trop techniques et auxquelles je suis bien allergique). Je connais beaucoup de gens dans l'IT qui sont bien meilleurs que moi en management, organisation de projet, méthodo agile, spécifications, workshops, challenge du besoin client...etc. et qui sont encore moins instruits que moi sur des trucs pourtant bien utiles dans leur périmètre comme le XML/XSD, les requêtes SQL, les Docker et autres Hibernatus, pour moi ça ne fait pas forcément d'eux de mauvais IT BA, même si pas tous n'ont un background d'ingénieur en informatique. D'ailleurs, ce qui fait la force des SSII, c'est justement la variété de profils de compétences dont elles peuvent disposer au travers de leur portfolio de ressources humaines très différentes. Si tout le monde savait tout faire, à quoi bon recruter... Soyons sérieux 2 secondes, faut arrêter de juger les gens sur un sigle qu'ils ne connaissent pas, chacun a ses forces et ses faiblesses ! Mais encore une fois, ce n'est que mon avis...

 
C'est pas surprenant et même compréhensible.
 
Les grosses structures ont des ingé de production qui s'occupaient de la partie CD tandis que les équipes projet / run avaient au mieux la main sur la CI (et pour ceux qui ont mis du pognon, des équipes d'usine logicielle pour s'occuper justement de la partie CI en détail).
 
Pour les entreprises tech / récentes, ça parait peut-être bizarre car ils ont plus de facilité à associer les 2 mais c'est très complexe pour des orga avec une séparation des tâches.

DDD ça existe depuis 2003-2004 (le bouquin d'Evans). CQRS il y avait des articles datant de 2011 déjà. Après c'était l'époque où on s'en tapait plus ou moins de l'IT qui était vu comme un centre de coût . Maintenant grâce à la startup nation et des mouvements style Software Craftmanship (voilà un autre buzz word ), c'est d'avantage mis en lumière.
 
Comme autre buzzword, vous pouvez ajouter microservices, event sourcing, event storming

Hello ca fait longtemps que j’étais pas passer par ici
 
comment ca va dans vos SSII en ce contexte post apocalyptique?
suite à menace de transaction, j’ai accepté un poste qui doit correspondre à un stage de 4ème année d’école d’ingé -_- (j’ai 8 ans d’xp)
 
les journées sont longues

 
... Et pourquoi ne pas avoir accepté la transaction ?

peur du contexte
besoin de temps pour réfléchir à la suite, je songe sérieusement à une reconversion (que ma SSII semblait prête à me proposer fût un temps)

Dans ce cas, vois ton stage de 4ème année comme une opportunité en or pour préparer ta reconversion, passer des formations en ligne, lire des cours tout en faisant semblant de bosser, etc.

c’est effectivement mon but

Tu peux tjs revenir vers eux pour une RC, si ce que tu fais te saoule.  
En ayant effectivement préparé la suite
 

J ai bien rigole en lisant les conneries de certains...
Desole mais j ai pas d autres mots.
Parfois faut redescendre de votre tour d ivoire les elites de la nation.
"Ne pas connaitre ci cd et bosser dans l informatique"
Sincerement c est tellement nombriliste de lire des choses pareil.
Evidement je ne connaissais pas donc ca me touche d autant plus.
Heureusement que quand j avais des informaticiens en ligne et que je dois les aider pour resoudre des soucis je n etais pas aussi ferme...
Et heureusement encore qu aujourd hui quand j integre ou conseille les clients sur l implementation de certaines solutions je n attends pas d eux qu ils connaissent tout le vocabulaire abreviation etc ...
Des sigles informatiques il en existe pletore et je doute qu on les connaisse tous
De plus le monde de devops bien que de plus en plus present n est pas encore present dans 100% des entreprises.
Bref , j ai oublie que j etais sur hfr pendant 3 min excusez moi...

OK jean Michel 1er degré.

Si je dois faire un choix entre quelqu'un(e) qui bosse avec les technos de 2021 sans forcément les maîtriser à fond, et quelqu'un d'autre qui bosse très bien, mais avec les technos de 2010, mon choix se portera très vite sur le premier candidat.
 
Si vous voulez tenir sur le long terme dans le secteur et rester bankable, réclamez des formations et/ou faites des formations gratuites même sans l'accord de votre N+1.
 

 
Les fondamentaux sont plus importants que les technos.

Un très gros bémol sur le point en gras.

Sans doute est ce parce que je suis moi même un ingé de prod de 2010 qui depuis à bifurquer sur autre chose, mais le fait est que je suis en profond désaccord avec cette affirmation.

Hum moyen d'accord. Le technique ça s'apprend avec des formations.
La manière de bosser et les soft skills assez peu.

Je préfère un mec qui réfléchit bien avant tout, quitte à ce qu'il apprenne.
Après je suis en prod, et on a pas des problèmatiques très poussées.

Après à candidats equivalents, forcément je prends celui qui connaît mieux les dernières technos. Et encore, fait faire gaffe que le mec s'ennuie pas...

Sauf que "les vieux" c'est pas forcément des gens qui maîtrisent les fondamentaux.
J'en ai croisé plein des admins sys "vieux de la vieille, qui gèrent de serveur mail et de l'active directory, et qui sont en mode "gneu gneu gneu le cloud c'est de la merde", et qui sont infoutus d'écrire un script de 50 lignes.
Ceux là n'ont pas su prendre le virage, et ralent parce qu'ils se retrouvent avec des jobs de grouillots mal payés

Et les fondamentaux évoluent non ?

Perso je ne jure que par le C et les commandes shell Unix/Linux de base. En gros l'informatique des années < 80  
Vive le GOTO (à utiliser avec modération quand même) !
Je chie profond sur la programmation objet et le java en particulier, et toutes les technos récentes.
Pour info j'ai travaillé sur un gros projet en C, et un gros projet en Java. J'étais bien plus à l'aise sur le projet en C ...
Je trouve que ça part de plus en plus dans tous les sens. Des tas de nouvelles technos qui nous obligent à nous former, et qui n'apportent rien au final, si ce n'est plus de complexité

Le comble c'est que je suis dans l'info, mais peut-être plus pour très longtemps ...

Edit : j'avais aussi développé il y a bien longtemps un jeu sur calculatrice, en C.
Bien plus tard je l'ai développé sous Android (avec Java donc), ça a été beaucoup, beaucoup plus laborieux. Temps de dev x5 facile.

c'est logique, c'est comme la science ; au 16e siécle tu avais des scientifiques qui étaient "généralistes", ajd ça n'existe plus, trop de complexité, de branche différentes.
En info c'est la même, on fait de plus en plus de chose, les systêmes évoluent, tu peux pas être spécialiste dans tout.
Exemple typique : dev un jeu sur calculatrice graphique vs dev un jeu sur smartphone

 
Tu aurais fait l'inverse, ça aurait été le même temps.
 
Même en ayant pas mal d'années de dev au compteur, il y aura toujours un temps d'investissement quand tu te lances dans un langage que tu ne maîtrises pas.  
Fais un 2ème projet et ce sera x4, puis ensuite x3, le temps que ça rentre.
 
La question c'est surtout de savoir où se trouvent les bonnes libs / API / docs pour tout faire simplement et proprement, sans avoir à réinventer la roue

« Quels conseils donneriez-vous à votre "vous" plus jeune, lors de son 1er jour dans une ESN ? »
https://www.reddit.com/r/france/com [...] %A0_votre/