Sérieusement ?Envoyé par MiaowZedong
Il y a un script Elisp pour ça
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Sérieusement ?Il y a un script Elisp pour ça
C'est vrai mais il y a un aspect plus structurel à tout ça.
J'ai vu plusieurs fois et récemment, des départements informatiques de grosses entreprises se faire racheter par des SSII. La tendance est inexorablement à l'externalisation.
Nous l'avons déjà démontré : la course effrénée à l'armement informatique que nous connaissons depuis quelques années, est au bénéfice exclusif des SSII. En effet, si une DSI claque ton son budget dans un projet mal défini et mal réalisé dont l'intérêt n'est pas prouvé (c'est un risque) ; elle aura tout perdu. Alors qu'une SSII qui réalise tout aussi mal un projet tout aussi mal défini et dont l'intérêt est tout aussi peu démontré ; elle est gagnante, car elle facture des jour/homme.
L'APEC, je viens d'aller sur leur site. Sur la premiere page de ma recherche (informatique en Rhone-Alpes, developpeur experimente, c'est pas la mort non plus comme recherche), il y a 20 annonces, dont :
17 annonces de SSII
2 annonces d'une grosse boite
1 annonce de PME
Si je precise le domaine "Informatique de gestion", ce qui represente plus de 50% des 758 offres de la region, on passe a 100% d'annonce de SSII sur la premiere page.
Je ne suis pas alle plus loin, mais pour moi, c'est assez revelateur du fait que l'APEC est comme lesjeudis, monster, ou n'importe quel autre site d'annonces d'emploi.
On trouve des articles sur les projets informatiques inutiles voire nuisibles dont j'ai parlé plus haut.
Erf, ce que je craignais est arrivé ... J'avoue ne pas avoir fait le test avant de poster. Je m'en remettais à mon expérience d'il y a 3-4 ans.
Il faudrait vérifier si en agence c'est toujours le cas. Même si je crains que si tu dis que c'est pour de l'informatique il te réoriente vers la "cellule Informatique".
Pour ce que j'ai expérimenté de la "cellule Informatique", ca revient ni plus ni moins à Expectra, Accenture, Stéria ou autre ...
Quoiqu'Expectra (ou au moins l'agence à laquelle j'étais rataché) avait un super suivi.
Ca parle surtout de la frustation des utilisateurs et du manque d'implication dont ils souffrent lors de la conception/mise en place d'outils informatiques. Encore moins du rapport avec les SSII.
L'utilité ne me semble pas y être mentionné. Encore moins que ce serait mieux sans ces outils "mal fichus". Genre Eclipse est une vraie bouse mais il me fait tout de même gagner un temps fou en développement.
Ça parle de projets qui compliquent la vie des utilisateurs au lieu de la simplifier. Ça ne parle pas technique car ce n'est pas tout à fait le sujet de l'article, mais l'écrasante majorité des projets que j'ai vus dans ma carrière étaient des calamités de ce point de vue : développement sans conception, rustines sur rustines, code hyper-redondant, BDD non normalisées...
Je ne sais pas ce que vous avez tous contre Éclipse...
Il existe de vraiment bons ingenieurs d'affaire en SSII, qui suivent reellement les consultants, se preoccupent reellement de leur bien etre, et soignent aussi le client.
Quoi que ceux que j'ai connu sont partis des SSII, mais ca doit encore exister :-)
En même temps le client s'enfou un peu tant que ca marche. En tout cas souvent. Durant les développements, je prends souvent à ma charge les petits problèmes non-prévus, on voit avec le client comment il est plus propre de réagir d'un point de vue fonctionnel.
Cependant il y a une limite de ce qu'on peut prendre en charge et ce qu'on ne peut pas. Donc on en vient à proposer N solutions avec le cout et les impacts. Et plus on se rapproche de la livraison et plus le client choisit la solution la moins chère et la plus rapide. Surtout vrai si les problèmes sont détectés en acceptance.
Un autre problème que je constate souvent et qui est mal assimilée par les développeurs. D'ailleurs j'ai pas vu beaucoup (voir aucun) article à ce sujet (et encore moins abordé dans l'enseignement) : la robustesse. Pour les clients au contraire ca doit être naturel. Pourtant cela a énormément d'impact sur le temps de conception, de développement et des traitements ; ainsi que le ressenti de l'utilisateur sur l'utilisation du logiciel au quotidien.
C'est une des sources principales de problème que je rencontre en support niveau 2 et 3, ou en acceptance.
A part ces quelques problèmes de design en matière d'ergonomie et de fonctionnement, sa lenteur, etc. Pas grand chose. Je peux pas m'en passer donc je le subis. On est loin de l'outil naturel et 100% efficace.
Deux trucs qui m'horrifient à longueur de journée : Obligé de faire un refresh manuel s'il n'a pas détecté automatiquement qu'une ressource a été modifiée : que ce soit pour les recherches ou certaines opérations de consultation. Génial le message qui indique qu'on doit rafraîchir une ressource, il peut pas le faire tout seul ?
Le deuxième truc, c'est qu'il fait croire qu'il fait quelque chose lors qu'il fait rien. Typiquement, le nettoyage et le déploiement d'application Web. Il faut répéter 100 fois la même opération avant que ce soit fonctionnel.
C'est vraiment pénible et si on ajoute tous les autres petits trucs, ca peut être très pénible durant les mauvais jours.
La robustesse c'est un peu une question de point de vue. Certain te diront que c'est parce que les specs sont trop incomplètes et n'indiquent pas tous les cas d'utilisations/le contexte.
D'un point de vue de l'utilisateur c'est quasiment le premier critère qui fait la différence entre une bonne application et une application "nuisible".
Rien de pire qu'une application qui ne délivre pas d'information sur ce qu'elle fait ou ne fait pas. Ou bien des explications claires et précises sur les problèmes rencontrés. Genre l'application qui t'affiche en boucle "An error has occurs" ; Génial ! Et sinon ?
Idem les applications qui génèrent des tâches mais tu n'as jamais aucun retour. Ca me fait penser à une application où on avait de gros traitements à lancer (plusieurs jours) et l'administrateur était averti par mail des fins de traitement mais pas ceux qui soumettaient les traitements !
La robustesse est l'affaire de tous : le donneur d'ordre, l'utilisateur, le concepteur, le développeur, etc. Ca va des messages des boîtes de dialogue au comportement de l'application en passant par les logs.
Enfin, il y a les cas généraux. Quand j'étais homologateur, je commençais toujours mes scénarios par un maximum de cas non-passants. Montant débilement élevé. Montant non numérique. 5 chiffres après la virgule. Multiple-clic superrapide sur le bouton(pour créér des doublons, ça marche bien si le bouton n'est pas immédiatement désactivé dès le clic). etc.....
ça, c'est quand même la base. Et ça me permettait toujours de lever quelques anomalies(et de justifier mon salaire même quand le fonctionnel était impeccable, ce qui était rarement le cas).
Pourtant, jamais je n'ai vu une spec dire "si on a 3 chiffres après la virgule, on doit refuser le montant"(après, peu importe comment). Mais c'est indispensable.
De même, l'application ne doit pas exploser(mais ça, c'est juste un truc qui arrive, ou pas, je ne peux pas le planifier). Le stagiaire(par ailleurs très bon) avait fait l'écran de stats, complet, en une seule requête SQL. Le temps a passé, la base à grossi, et la requête a fini par dépasser le time-out programmé. Et boum l'appli!!! (seule solution, fermer le navigateur).
Ca, c'est un manque flagrant de robutesse. Indétectable au test initial(puisque la base est riquiqui.....), inspécifiable(la vitesse d'affichage de l'écran des statistiques ne doit pas dépendre de la taille de la base....sans blague?), et pourtant à éviter. Les programmeurs se sont bien arrachés les cheveux pour tirer quelquechose de l'existant, d'ailleurs.
Et c'est le genre de truc qui s'apprend avec l'expérience. Le stagiaire était tout fier d'avoir fait tout l'écran en une seule requête, ses profs pouvaient être fiers de lui. En fait, non. Plein de petites requêtes séparées auraient été moches, mais auraient marché, même avec une base pleine.
Oui, enfin là c'est un gros problème de conception : on sait qu'il convient de séparer un maximum le modèle de données de l'affichage. Donc celui qui est content de fabriquer un plat de nouilles indémêlable entre les deux, il a rien pigé au concept.
T'as beau séparer une application en autant de couches que tu veux, elles partagent toutes le même PID, voir un même groupe réduit de thread. Donc si t'as un ou plusieurs process qui plombent ton CPU et/ou ta mémoire, toutes les couches sont en carafes.
C'est certain. Et il y a même des "chances" que la superposition de couches plombent les perfs générales.
D'accord mais quel est le rapport ?
HS, mais c'est pour ça entre autre qu'on a inventé l'AOP et la metaprogrammation.
Ce topic est moribond et de nombreuses questions sont restées en suspens.
Tout à fait, par exemple cette question n'a pas reçu de réponse de votre part.
Avez-vous attaqué chacun de vos employeurs pour que cessent ces abus ?
Peut-on avoir une réponse ? Si vous avez effectivement agit pour faire changer les choses ça offrirait un témoignage intéressant qui pourrait servir à d'autres.
Parce que vous êtes très virulent mais je n'ai pas l'impression que vous agissez concrètement.
En effet, au temps pour moi, j'ai omis de répondre à cette question. La réponse est "non", pour la simple et bonne raison que j'ignorais tout de cette loi jusqu'à cette année.
Mais cette année, j'ai dénoncé mon employeur actuel à l'Inspection du Travail ; une procédure est en cours.
Par ailleurs la connaissance de cette loi m'a été d'un grand secours lorsque j'ai dû négocier avec mon employeur pour qu'il m'accorde l'autorisation d'absence pour un CIF ; et elle pourrait bien me servir à nouveau dans l'avenir.
Pourrait-on avoir des précisions ? Cela peut être intéressant
Ça sonne un peu comme du chantage.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager