Reprise du message précédent :

Je t’envoie un MP une fois rentré  

 
En l'occurrence non, ce n'est pas cet assureur italien (et y en a pas 36 )
L'externalisation IT (nearshore et/ou offshore, tout ou partie) est le lot de pas mal d'entreprises tu sais...
 
Le projet est en cours de mise en oeuvre: certaines équipes ont déjà du renfort externe issu de ce centre de services, mais pas encore opérationnel à 100%.
 

Au passage, puisqu'on en parle ces derniers temps : si vous avez des besoins ou que vous identifiez des besoins en tests de performance / charge, n'hésitez pas à me shooter un MP.
On n'est pas des ingrats, y'a toujours un joli billet pour les camarades facilitateurs

On recrute et je forme, donc si certains se cherchent une voie à explorer, même réflexe, un MP.

Ça consiste en quoi ce genre d'activités d'ailleurs ?
 
C'est liée à la partie dév d'un projet avec tout ce qui peut être mesuré/amélioré sur la chaîne ?

Dans la plupart des grosses organisations, le test de performance est arrivé par la porte du test de charge. Ce sont des tests au niveau système (attention, système au sens applicatif et pas au sens OS).

Le test de charge consiste à identifier les scénarios métier à tester, à les automatiser, et à lancer des tests simulant différents niveaux de charge afin d'identifier des anomalies liées à la charge. Tu peux donc avoir plusieurs dizaines, centaines, milliers d'utilisateurs virtuels en parallèle qui prennent des mesures de temps de réponse tout en faisant le boulot fonctionnellement. En parallèle, on branche des sondes sur tous les composants de l'architecture pour comprendre d'où viennent les anomalies et les corriger.

Le test de performance est un type de test, donc ça peut être réalisé aussi bien au niveau unitaire (par exemple dans le code), qu'au niveau composant (par exemple auprès d'un WebService isolé), qu'au niveau système (cf au dessus) ou encore utilisateur (par exemple performance des interfaces, des navigateurs, etc.). Le test de charge est donc un sous-ensemble des tests de performance.

Avec l'avènement des usines d'intégration/déploiement/surveillance en continu, on intègre de plus en plus des tests de performance dans les pipelines, donc à la suite des builds/packaging/provisionnements à la volée. Donc on connecte des solutions de test de charge avec des outils comme Jenkins pour faire de la performance dans les environnements de développement ou de qualification fonctionnelle. Le but est d'identifier les anomalies de performance le plus tôt possible, plutôt que de devoir attendre les tests de charge qui ont de fortes contraintes au niveau infrastructure (le dimensionnement doit être proche de la production pour que les mesures et les problèmes identifiés aient du sens), et qui arrivent donc tard dans la vie d'une application.

Le gros du boulot c'est donc d'automatiser les scénarios d'utilisation, de modéliser les scénarios de charge qui peuvent survenir, d'analyser les mesures réalisées et de conduire l'activité de tuning pour 1. corriger les anomalies de performance 2. rendre les applications plus efficientes.

Ca fait 10 ans que je fais ça et je m'éclate
J'ai toujours cherché à optimiser ce que je faisais dans les jeux, et j'aime le côté "on casse tout" de l'activité. On parle aux techniques mais on parle aussi aux métiers, et j'adore ce pont.

En tout cas tu le vends bien et c'est clair
 
C'est le genre de trucs que je ferais peut être plus tard tiens du coup quand j'aurais plus de bouteilles au final.
 
Ça me fait penser à la biochimie et mon premier domaine d'étude du coup dans la mesure où on fait péter des cellules :
 
on regarde les composants et les réactions dans lesquelles ils sont impliqués pour reproduire des chaînes de réaction et voir comment c'est ordonné.
 
Après on prend des enzymes différentes et on voit si ça change les vitesses de réactions.

Ce qui se rapproche le plus de ce que tu évoques c'est le reverse engineering.
L'activité de test de performance inclut historiquement un peu de cette approche, mais plus par défaut que par choix.
 
La façon dont les outils fonctionnent est qu'ils créent un proxy virtuel entre le client de l'application et le serveur auquel le client parle. Ce proxy voit passer toutes les requêtes sortantes et toutes les réponses entrantes. Ca permet d'établir une sorte de "portrait robot" de la façon dont le client et le serveur communiquent.
 
Quand tu as de la chance, tu peux parler aux devs. Donc tu sais que le champ "screugneugneu" qui a une valeur en "123987362" correspond à un calcul effectué comme-ci ou comme-ça, ou encore que telle valeur doit être réutilisée plus loin à telle étape dans tel champ.
 
Quand tu n'as pas de chance, et c'est historiquement comme ça car les testeurs n'ont pas la possibilité de parler aux devs (bravo les orgas les gars), tu dois comprendre tout ça tout seul. Au final, quand tu vois une valeur dans une requête, ton premier réflexe est de faire une recherche dans toutes les réponses reçues précédemment pour voir si cette valeur a été présentée par le serveur, et comprendre son sens et sa longévité (identifiant de session qui sautera à chaque déconnexion ? numéro de commande qui marche pour toute l'itération ? date du jour ? numéro de la direction régionale en charge de ce type de dossier ?). Si ce n'est pas le cas, tu essaies de deviner comment elle a été calculée localement (par exemple un bête timestamp). Quand c'est ni l'un ni l'autre, tu as un mystère à résoudre
 
Automatiser une application au niveau protocolaire peut être assez touchy, et ça fait partie du plaisir que d'arriver à mettre sur pieds un framework qui te permet de passer très rapidement d'un enregistrement à un replay fiable dans le temps et en volume (car à terme il y aura des utilisateurs concurrents).

Ça a clairement l'air tendu techniquement à faire mais ça reste super cool dans le principe.
 
C'est un peu le genre d'approche qui est abordée sur root-me avec les différents challenges qu'ils proposent.
 
Je suis pas au level pour l'instant mais peut être qu'on en rediscutera dans quelques temps
 
Pour en revenir au sujet sinon.
 
J'ai reçu un mail d'une SSII me disant qu'ils ont trouvé un réel intérêt et qu'ils ont retenu ma candidature dans la cadre d'un recrutement sur projet.
 
Mais avec rien derrière.
 
Je trouve ça magique.

Pas besoin de tests, tout le monde sait que les problèmes viennent de la BDD

des utilisateurs  

 
ICC, Interface Chaise-Clavier

http://www.leparisien.fr/economie/ [...] 572807.php
 
On dirait un article sur les SSII    
 

Moi j'ai toujours trouvé ca amusant qu'une banque considere un CDI dans une SSII comme un emploi non precaire

 
Un CDI, que ce soit en SSII ou ailleurs, ça reste un CDI. C'est à la SSII d'assumer le risque de l'intercontrat : contrairement à l'intérim (sauf si CDI-I, où c'est l'agence qui assume ce risque)

 
Quand on sait la façon dont certaines SSII gère ce risque ...

 
... Alors ça c'est un autre problème

 
Malheureusement des équipes de test avec l'esprit carré, expérimentées et fonctionnant à la ISTQB sont très rares dans la réalité, sauf sans doute dans les projets traditionnellement très structurés. Le point faible de l'ISTQB c'est que c'est encore assez récent, donc peu connu et compris, et la mode des méthodes Agile ont tendance à massacrer cette manière de travailler.
 
 
 
   
 
 
 
 

Comment?
Le risque de licenciement reste le même partout dans n'importe quelle boîte.

Fin je sais pas, quand je regarde l'actualité j'ai pas l'impression que les SSII sont les pires en terme de licenciement.

Si la SSII ne te trouve pas de mission, même si ce n'est pas de ta faute, tu seras licencié tôt ou tard... Alors qu'en interne, le CDI est beaucoup plus solide, si tu ne commet pas de grave erreur ou que tu ne fais pas l'objet d'un licenciement économique, tu es assez tranquille...

 
Intéressant ta démarche. Je suis dans la même situation (ingé système) et ma SSII ne trouve que très peu de missions système / infra. Ce qui me plaît le plus, c'est comprendre pourquoi une machine est tombée, pourquoi une machine perf moins bien qu'une autre équivalente, et plus généralement aider les devs à faire leur boulot en les aidant à automatiser tout un tas de tâches ou en leur montrant comment améliorer leur build, leur infra, etc. Mais aujourd'hui tout ça c'est genre 5% de mon boulot, le reste c'est de la bureaucratie pour avoir des accès ou des choses faites vu que quasi tout est infogéré. J'ai donc démissionné mais ma SSII veut me garder donc j'ai pris un congé sans solde pour faire un peu le point, ensuite ils me chercheront une autre mission... Mais quand ils ont cherché précédemment j'ai pas eu l'impression qu'ils avaient grand chose, je pense que j'aurais pu trouver plus vite.
 
Bref je réfléchis à faire du dev, j'en ai fait qu'en école, ça me déplaisait pas, mais j'ai pas envie non plus de passer mon temps à faire des if en java sur un progiciel un peu merdique. Et j'ai la vague impression que c'est quand même la majorité du marché quoi qu'on en dise. J'aimerais bien bosser sur des applis un peu bas niveau, des lib système, du noyau, de l'embarqué... Mais ça reste des niches et en plus il faut pas mal d'expérience, et si ça se trouve dans 10 ans je serais de nouveau inemployable car trop vieux. Je bosserais avec plaisir aussi sur des trucs plus haut niveau comme de la perf (améliorer des algos, ce genre de trucs) mais pareil sans avoir 10 ans d'xp je trouverais rien je pense.
 
Et ça me file un peu un coup de blues. En gros tu fais de grosses études (master, ingé...) puis tu te retrouves à faire des tâches vraiment basiques et tu finis par jamais avoir assez d'xp pour faire les trucs vraiment cool. Et un beau jour on te dit que t'es trop vieux Mais bref je vais profiter de mon congé pour me changer un peu les idées et d'ici mon intercontrat j'espère être motivé pour bosser du C ou du Rust par exemple.

Disons que je vise l'architecture à moyens/longs termes.
 
Connaître un langage qui permet de faire de la virtualisation d'infra ça va dans ce sens notamment parce que ça permet à mon avis une meilleure employabilité et en plus ça a du sens par rapport à de l'archi.
 
Je vais faire un petit saut côté sécurité informatique avec du python, des petites choses basiques pour avoir aussi un pied là dedans.
 
De toute façon je suis juste junior sur ma position et j'ai pas encore de spécialité.

Oui clairement python + les outils dont t'as parlé avant (chef puppet ansible fabric) c'est le complément idéal pour mettre un pied dedans si tu fais de l'infra. En fonction des technos que tu vises tu peux essayer powershell aussi (pour vmware), node.js, etc.

Parce que tu penses qu'une société, de services certes, peut s'asseoir sur le code du travail ?

Comment mesures tu cette "solidité"?

Si tu restes trop longtemps en intercontrat, la SSII trouvera une excuse bidon pour te licencier

Faut pas trop généraliser quand même.
D'autre part, c'est attaquable auprès des prud'hommes.

Oui, mais aller aux prud'hommes ça prend du temps, ça coûte de l'argent (avocat), et on n'est jamais sur à 100% de gagner. Donc pas mal de gens ne se lancent pas dans ce genre de procédure. Comme en plus ce sont souvent des jeunes diplômés, qui ne connaissent pas trop le droit du travail... Pour un salarié qui va au bout de la procédure, il y en a peut être 10 (chiffres au hasard) qui laisseront tomber
Au final, si le coût de l'amende + dommages et intérêts est inférieur à ce qu'auraient couté les 10 autres en intercontrat, la SSII est gagnante. J'avais même lu quelque part (peut être sur ce forum?) que les condamnations aux prud'hommes étaient même prévues dans leur budget...
 
Bien sûr il ne faut pas généraliser, mais chez les "viandards" j'ai peur que ça soit assez répandu...

C'est effectivement répandu, mais ça reste illégal comme le dit lA cLaSsE a dAlLaS. Donc pas de raison d'en avoir peur, il y a des recours, vous toucherez le chômage, etc. Bon ça fait chier quand ça arrive je le conçois. Mais c'est pour ça qu'il faut faire gaffe aux buveurs de sueur.

Ce que j'essaie de dire, c'est que les licenciements abusifs y en a partout.
Faut pas se focaliser sur les SSII sous prétexte que notre matière première est l humain.
C'est un raccourci assez facile et d'autres sociétés n'hésitent pas à faire pire.

Enfin dans les grosses Cogip en général les syndicats sont un minimum actifs, il y a donc un soutien potentiel vers qui se tourner en cas de soucis.
En SSII les syndicats sont inexistants et de plus une grande partie des salariés sont en mission chez un client, ce qui ne facilite pas le tâche pour savoir vers qui se tourner.
Dans les PME ça va dépendre, certaines vont avoir quelques représentants actifs, d'autres non.
 
Un autre facteur qui biaise peut-être la vision sur les SSII c'est le fait qu'il y a beaucoup de jeunes diplômés qui ne connaissent pas le code du travail ni la convention collective ou les accords d'entreprise. Avec le temps on s'y intéresse mais une partie est déjà passée chez des clients finaux.

 
Ma SSII a des syndicats très actifs, d'ailleurs je compte me syndiquer à ma reprise. J'étais en interne avant dans une autre boite (assez grosse) et il n'y avait pas de syndicats, ou alors ils étaient très discrets Donc oui, que les jeunes se fassent plus avoir, c'est très possible, mais rien à voir avec SSII vs COGIP, et puis on peut aussi commencer en COGIP et finir en SSII y a pas de raison.

 
Les conventions collectives de type Syntec sont pour les salariés IT en France une immense farce, même le Medef ne l'aurait pas imaginé en rêve.
 
Quand aux syndicats..à moins d'être routier ou conducteur SNCF, secteur où il suffit de 5 % d'enragés pour tout paralyser, tu emmerdes très peu de monde en faisant grève un lundi derrière Eclipse ou CouchDB.
 
Et de toute manière la négociation du salaire et du job dans le privé se fait entre 2 personnes, la porte fermée.
 
C'est juste qu'ils savent pertinemment, compte tenu du marché et de la mentalité, qu'ils trouveront toujours un pigeon pour accepter le travail au prix qu'ils ont décidé, c'est comme ça.

Et quelles sont les bonnes SSII, je veux dire les moins pire ? Alten, Altran ?

Les petites crèmeries ont plus de chances de pouvoir te donner ce que tu recherches.

Évite Escroc.nocom

Comme dit ici : ce qui va être pire ou pas pire, c'est le client chez qui tu es.
Sinon il reste les intégrateurs (qui font souvent SSII a coté, mais séparent bien les deux activités), les infogéreurs et les start up en tout genres.
 
Après j'aurais tendance à dire : une ssii qui a un portefeuille client solide. Mais ça ne protège de rien, surtout pas d'être envoyé en mission à pétaouchnok.
 

Oui mais dans ce systèmes, les SSII font le "sale boulot". C'est pour ça que les clients passent par elles. Si lles clients passaient par de l'interim ou des CDD => risque de voir la personne se barrer du jour au lendemain.
Grâce aux SSII le client gagne les 3 mois de préavis de départ pour les cadres, tout en ayant la flexibilité.
 
Rien que le système du "je bosse ailleurs que chez mon employeur" fait que tu tombes dans une division par zéro pour pas mal de loi et reglements, qui datent de l'ère industrielle.
 

Tu crois vraiment qu'il existe une conspiration des sociétés pour confier aux ssii le "sale boulot" ?

Tu peux en dire plus ?

Pas besoin de conspiration! Le  but de ces intérmédaires est bien de gérer la flexibilité, le plus souvent pour suivre la capacité. C'est leur valeur ajoutée. Il faut juste ne pas être naïf.
Quand je dis "sale boulot", je parle pas du boulot à faire pour  le client, mais bien du boulot de flexibilisation.

 
Tu tiens ça d'où?

http://www.zdnet.fr/actualites/chi [...] 790265.htm

Merci Guimo!!!
 
 
Sinon, pour toucher le chômage en démissionnant (après 5 ans d'ancienneté), c'est pour quand?