Discussion :

[Glutinus]

Non je ne pense pas trop exagérer. Par exemple dans le film sur Kerviel, on lui fait bien comprendre et ceux de l'IT qu'ils sont là pour le support et font pas gagner de l'argent à la boîte et sont qu'un coût. Quand tu sais après que ces mecs finissent dans les plus hautes sphères, tu vois l'image que renvoie l'informatique (l'image a quand même changé donc ces dernières années).

C'est pas pour rien si on a fait bcp d'offhsore à un moment afin de réduire ce coût. Les boîtes mettant l'informatique au coeur de leurs stratégies ne sont pas encore si nombreuses AMHA.

Oui... en 2008 -_-' on était déjà dans les mouvances de baisses de coûts. L'époque COBOL c'est... pfffiout bien avant, hein (et je dis pas que c'était la panacée, mais je pense que c'était bien mieux).
Quoique quand j'ai commencé en 2006 et ce jusqu'à l'affaire Kerviel justement, on avait beaucoup plus de moyens pour faire un projet, même s'il y avait déjà de l'off-shore et des centres de compétence. Certes avec des problèmes qu'on a aujourd'hui : collègues avec des poils dans la main, filous, commerciaux débilos etc. mais au moins les clients alignaient des TJM assez élevés et on était 10 pour faire le boulot de 9. Ça a dégringolé très vite après, du moins de mon point de vue.

Qui plus est, tu parles des traders, je crois bien que c'est une des espèces les plus détestables que j'eusse à rencontrer ^^

[Carhiboux]

J'avais pas encore pris le temps de lire l'article, c'est maintenant fait.

Je trouve que c'est assez bien vu, même si ça commence un peu trop sur une anecdote personnelle qui n'apporte finalement pas grand chose.

Elle identifie bien la situation de rente des grosses SS2I dans les entreprises où les services achats n'acceptent de travailler qu'avec quelques sociétés référencées.

Elle aborde de manière factuelle en citant les textes des loi le fait que la régie est bien souvent du délit de marchandage. Je pense que nombreux sont les prestataires qui ont déjà étés mis en régie pour plusieurs mois, voir années, sans aucun contact ou presque avec leur SS2I!

Elle aurait sans doute pu approfondir plus sur le lobbying de Syntec par exemple.

Puis même si elle ne voit pas les choses à travers le même prisme que moi qui suis côté technique, c'est intéressant d'avoir d'autres points de vue.



Pour rebondir sur les derniers commentaires qui débattent de l'intérêt à internaliser ou pas l'informatique, il faut bien comprendre que l'informatique n'est qu'un outil pour beaucoup d'entreprises. Ce n'est pas de l'informatique qu'elle vendent, ce sont des produits ou des services.

Je vais prendre un exemple que je connais bien, les banques.

Avant l'informatique, tout était fait sur papier. Aucun besoin d'informaticien donc, mais des besoins de comptables, de secrétaires, pour recopier, consolider, etc...

Est arrivé l'informatique, qui à permit de s'affranchir d'un grosse partie du papier, et qui est devenu le référentiel centralisé, ce qui à permis de lancer d'autres services bancaires, etc... Là on avait clairement besoin de développeurs, de techniciens pour maintenir en état opérationnel les serveurs, etc, etc...

Qui dit que demain, une nouvelle technologie n'apparaitra pas qui ne nécessitera plus de développeurs? On peut rêver, mais on est sans doute plus si loin que cela du développement en langage naturel! Bref, peut être que demain, il y aura un changement de paradigme et que les développeurs ne seront plus utiles. Pour autant, la banque continuera à faire de la banque tant qu'il y aura le besoin de banques.

Donc si une banque internalise tout, et que dans un an, dans dix ans, il y a des changements de paradigme, alors c'est des dizaines, des centaines, des milliers d'employés qu'il faut pouvoir licencier. Or, en France, il est compliqué de licencier, surtout si l'entreprise fait d'énormes profits. Il faut mettre en œuvre de couteux plans sociaux, essayer de recaser les salariés, etc, etc... Peut être une des raisons majeures pour lesquelles les SS2I sont si prisées en France d'ailleurs?

A contrario, si vous avez externalisé tout ou partie de votre informatique (ou d'un autre pan qui n'est pas votre métier de base) :

=> Vous pouvez mettre fin au contrat de sous-traitance, ce sera à la SS2I de licencier en masse au besoin.
=> Vous maitrisez vous masse salariale puisque les sous-traitants ne sont pas dans les effectifs de l'entreprise.
=> Les sous-traitants ont souvent moins de congés et de RTT, ils dont plus présent que les internes.
=> Ils contribuent généralement autant qu'un interne, mais seul l'interne devra toucher une miette des bons résultats (intéressement, participation, etc...).
=> La sous-traitance est la voie la plus commune pour être embauché chez un client final, cela fait que la plupart des prestataires essayent de bien travailler (ou de le faire croire). Et même parmi ceux qui ne voudraient pas être internalisés, beaucoup vous faire leur job par acquis de conscience.
=> Vous éliminez en grande partie le risque qu'un salarié fasse son job le temps de la période d'essai et ne fasse plus rien ensuite. Si un presta fait ça, un appel au commercial, et bien souvent, il sort du paysage.

Bref, il y a des inconvénients qui ont été listés précédemment (risque que le SI soit une boite noire pour les interne, etc...), mais du point de vue des dirigeants de ces entreprises, c'est un risque qui est souvent méconnu et ignoré.

[yolle]

Qui dit que demain, une nouvelle technologie n'apparaitra pas qui ne nécessitera plus de développeurs? On peut rêver, mais on est sans doute plus si loin que cela du développement en langage naturel! Bref, peut être que demain, il y aura un changement de paradigme et que les développeurs ne seront plus utiles

+1. C'est de cette façon que je vois l’évolution du métier de développeur. Je pense qu'il est appelé a disparaitre a moyen terme, dans peu de temps, il devrait être possible de programmer en langage naturel (en respectant un certain formalisme bien sur). il suffit de voir les progrès de certains systèmes qui analysent la voix humaine (intelligence artificielle faible). C'est pour cela que l(on veut enseigner l'informatique des le plus jeune age, pas pour en faire des pisseurs de code mais pour structurer leurs esprits et ainsi communiquer avec la machine plus efficacement.

Les banques/assurances sont passées de plusieurs dizaines de milliers d’employés (Papier: Employés) => a plusieurs milliers (Informatique : Employés + informaticiens). Leurs buts a termes est de passer a plusieurs centaines (Informatique : Employés très spécialisés)... Les agences bancaires n'existent déjà presque plus, tout se fait par des centres d'appels et des sites web.

Pour le reste, son article ne parle pas d'internalisation ou d'externalisation, mais de la disparition des SSII au profit des free-lances...

[yento]

C'est très largement faux, et ca explique n grande partie pourquoi la France n'a pas une capacité d'innovation très forte dans notre domaine.

Pas convaincu d'un point de vu strictement financier.

Un element en grosse entreprise type banque facture 400-500 par jour, soit 80-100k par an. Compter 200 jours travailles a la louche, excluant vacances, RTT et maladie.

La meme personne ferait 40-50k en interne (paris), 5k d'interessement/participation/stock, +5k de bonus/prime annuel, +25% de charges sur le total. Ca fait tout de suite 60-80k en salaire direct.
A cela s'ajoute quelques k entre CE, mutuelle, retraite, transport, ticket resto et avantages divers. Ca s'additione vite mine de rien.

Au final, la SSII coute un poil plus cher, mais c'est pas significatif.

Par exemple dans le film sur Kerviel...

Deja il etait dans un role de support secondaire, donc tres loin de rapporter de l'argent, et puis un drame en film n'est pas forcement représentative de la realite.

Si on veut parler technologie en finance, le minimum c'est d'etre en front office, préférablement en prop trading shop, type HFT ou quant fund. (Aucun des deux n'existent a Paris, probablement a cause de la situation fiscale).

[yolle]

La meme personne ferait 40-50k en interne (paris), 5k d'interessement/participation/stock, +5k de bonus/prime annuel, +25% de charges sur le total. Ca fait tout de suite 60-80k en salaire direct.
A cela s'ajoute quelques k entre CE, mutuelle, retraite, transport, ticket resto et avantages divers. Ca s'additione vite mine de rien.

Oui c'est cela. Les Achats se sont arrangés pour que cela ne leur coutent pas plus cher qu'un Interne.

[Chezkele]

je sais bien qu'un commercial qui vend de l'ERP n'a pas besoin de savoir installer le produit, mais on explique quand même un minimum voire on laisse utiliser l'outil pour comprendre la plus-value...

Je vais pas postuler en tant que commercial en concessionnaire Renault alors que j'ai pas le permis. "Vous voyez la tuture ? Elle est rouge... et... elle va vite, oui oui, 90km/h ! comment ça un break, vous voulez la casser ?

Des commerciaux qui n'y pinaient absolument que dalle, je peux dire que j'en ai croisé plus d'un.

Exemples:
- J'en ai eu un qui avait une licence d'archéologie préhistorique alors qu'il devait vendre des développeurs de code scientifique. Il m'a sorti un jour, tout fier: "moi je fais du business!", alors qu'il ne faisait qu'un vulgaire travail administratif, en pipeautant clients et prestas dès que cela était possible. Il s'est finalement fait virer parce qu'un projet qui fonctionnait en plateau à généré des retards qui ont eu un coût colossal. Pour le coup ce n'était pas du tout de sa faute (même moi qui était diplômé depuis deux ans j'ai compris tout de suite que c'était le genre de truc infaisable dans les temps), mais le gars qui gérait les techniques sur place a démissionné, donc c'est le commercial qui n'y comprenait rien et se contentait de passer une fois par mois pour dire bonjour que l'on a viré (avec son N+1 qui lui devait passer sur place une fois par an). C'est le revers de la médaille pour ces postes-là: il n'y a rien besoin de savoir, mais on sert de bouc émissaire.
Avant de partir, alors qu'il réfléchissait tout haut à ce qu'il pouvait faire, il a fini par lâcher "quand même, j'y connais pas grand-chose". Mais comme tous ceux dans cette situation dont j'ai suivi le parcours, le mec a rebondi au même genre de poste dans une autre boîte, et il est même monté en grade.

- J'en avais accompagné une autre chez un client en tant que "conseiller technique". Une femme fort sympathique au demeurant. Mais quand il s'est agi de faire le compte-rendu de ce que le gars nous avait raconté, elle m'a sorti "c'est quoi des biotecs? Il répétait tout le temps biotecs, biotecs." J'ai fait "Ah, des bibliothèques...". Elle ce n'était pas la commerciale de base, elle était déjà N+X, elle est maintenant (quelques années plus tard)...directrice générale d'une boîte assez importante.

[Pyramidev]

Qui dit que demain, une nouvelle technologie n'apparaitra pas qui ne nécessitera plus de développeurs? On peut rêver, mais on est sans doute plus si loin que cela du développement en langage naturel! Bref, peut être que demain, il y aura un changement de paradigme et que les développeurs ne seront plus utiles.

À partir du moment où on programme un ensemble de règles formelles dont l'ensemble forme un système un tant soit peu complexe, on a besoin de bons développeurs pour que ce système soit compréhensible, maintenable et évolutif. Si les développeurs ne sont pas assez bons, alors ça se passe mal. Alors si on confie la conception du système à des gens qui ne sont même pas développeurs...

Par exemple :

• Un système complexe doit être décomposé en sous-systèmes plus simples dont on connaît les entrées et les sorties. Si on confie l'architecture du système à des gens qui ne sont pas assez forts, on se retrouve avec une usine à gaz monolithique incompréhensible dans laquelle tout dépend de tout et dans laquelle il est difficile de changer quoi que ce soit.
• Il faut mettre en place des indirections pour factoriser des règles. Si on confie l'architecture à des gens qui n'ont pas l'habitude de factoriser alors, dès qu'il faudra faire un changement simple, il faudra changer plein de règles différentes éparpillées partout au lieu d'une seule.
• Il faut mettre en place des tests automatisés. Si on confie la conception à des gens qui ne sont pas sensibilisés à ça, alors on se retrouve avec un système bogué, plus lent à tester et plus difficile à faire évoluer.
• Il faut mettre en place une gestion d'erreurs rigoureuse et éviter les sources de complexité inutiles pour faciliter la maintenance. Si on confie la conception à des gens qui ne sont pas sensibilisés à ça, alors on se retrouve avec plein de règles du style "quand on a tel input bizarre en entrée alors, au lieu de signaler une erreur, on adopte tel comportement par défaut". Plus tard, tout le monde oublie ces règles bizarres et, quand le programme a un comportement différent de celui que l'utilisateur attend, cela devient une plaie pour la maintenance.
• Etc.

Programmer un système formel complexe, c'est tout un art. Et ce n'est pas un nouveau paradigme magique qui va permettre d'y passer outre.

[Carhiboux]

À partir du moment où on programme un ensemble de règles formelles dont l'ensemble forme un système un tant soit peu complexe, on a besoin de bons développeurs pour que ce système soit compréhensible, maintenable et évolutif. Si les développeurs ne sont pas assez bons, alors ça se passe mal. Alors si on confie la conception du système à des gens qui ne sont même pas développeurs...

Par exemple :

• Un système complexe doit être décomposé en sous-systèmes plus simples dont on connaît les entrées et les sorties. Si on confie l'architecture du système à des gens qui ne sont pas assez forts, on se retrouve avec une usine à gaz monolithique incompréhensible dans laquelle tout dépend de tout et dans laquelle il est difficile de changer quoi que ce soit.
• Il faut mettre en place des indirections pour factoriser des règles. Si on confie l'architecture à des gens qui n'ont pas l'habitude de factoriser alors, dès qu'il faudra faire un changement simple, il faudra changer plein de règles différentes éparpillées partout au lieu d'une seule.
• Il faut mettre en place des tests automatisés. Si on confie la conception à des gens qui ne sont pas sensibilisés à ça, alors on se retrouve avec un système bogué, plus lent à tester et plus difficile à faire évoluer.
• Il faut mettre en place une gestion d'erreurs rigoureuse et éviter les sources de complexité inutiles pour faciliter la maintenance. Si on confie la conception à des gens qui ne sont pas sensibilisés à ça, alors on se retrouve avec plein de règles du style "quand on a tel input bizarre en entrée alors, au lieu de signaler une erreur, on adopte tel comportement par défaut". Plus tard, tout le monde oublie ces règles bizarres et, quand le programme a un comportement différent de celui que l'utilisateur attend, cela devient une plaie pour la maintenance.
• Etc.

Programmer un système formel complexe, c'est tout un art. Et ce n'est pas un nouveau paradigme magique qui va permettre d'y passer outre.

Tu as tout à fait raison,

mais là où il faut aujourd'hui 1000 jours homme pour mettre en place une nouvelle appli il n'en faudra peut être plus que 200, puisque la phase de réal telle qu'on la connait actuellement n'existera quasi plus. On aura des spécialistes qui feront un cahier de charge béton qui servira d'entrée pour la création du service désiré.

Maintenant, contrairement à Yolle, je n'y crois pas pour demain. Il reste beaucoup de chemin à parcourir pour arriver à ce résultat, du moins pour les applications complexes. Et puis il y aura forcément une réticence initiale à faire confiance à un code généré automatiquement à 100%, que ce soit pour des raisons de sécurité, etc, etc... Mais on y arrivera surement dans plusieurs décennies.

[Darkzinus]

On aura des spécialistes qui feront un cahier de charge béton qui servira d'entrée pour la création du service désiré.

On en est très loin… Quand je vois les trous dans la raquette des spécifications en informatique de gestion … Avant que cela soit transposable en code ...

[Glutinus]

Si on veut parler technologie en finance, le minimum c'est d'etre en front office, préférablement en prop trading shop, type HFT ou quant fund. (Aucun des deux n'existent a Paris, probablement a cause de la situation fiscale).

Y a du THF (Trading Haute Fréquence) en France, mais évidemment bien plus marginal qu'aux US par exemple. Très contrôlé par l'AMF, je ne sais pas à quel point ce dernier est moins des vendus que la SEC.
Peut-être que le scandale de la SG en 2010 (vol de code) peu de temps après Kerviel fait qu'on fait plus profil bas, peut-être plus que les capacités techniques...

[yolle]

Maintenant, contrairement à Yolle, je n'y crois pas pour demain. Il reste beaucoup de chemin à parcourir pour arriver à ce résultat, du moins pour les applications complexes.

La plupart des appli ne sont pas complexes, il suffit de voir le nombre de gens qui font de la TMA. Cela sera plus rapide. Des qu'ils auront compris l’intérêt pour eux de ce genre de techno (diminution de la masse salariale), ils vont s y engouffrer. On vas rapidement assister a une montée en puissance de fonctionnels pointus capablent de modéliser correctement un SI, un base etc etc ..... Et cela ne prendra pas plusieurs décennies.

[Mat.M]

Bref, peut être que demain, il y aura un changement de paradigme et que les développeurs ne seront plus utiles.

bonjour, ça je n'y crois pas du tout car lorsqu'on regarde les projets informatiques voire technologiques cela tient plus des 12 travaux d'Hercule qu'autre chose ( l'EPR de Flamanville,le logiciel de paie des militaires Louvois..)

Ensuite faire un outil de développement qui permette de programmer en langage naturel je n'y crois pas non plus car on va vite faire face à un problème de nominalisme...

[Carhiboux]

On en est très loin… Quand je vois les trous dans la raquette des spécifications en informatique de gestion … Avant que cela soit transposable en code ...

Bien sur, parce que actuellement, ce sont les devs qui compensent les lacunes (parfois). Mais cela peut évoluer.

[el_slapper]

La plupart des appli ne sont pas complexes, il suffit de voir le nombre de gens qui font de la TMA. Cela sera plus rapide. Des qu'ils auront compris l’intérêt pour eux de ce genre de techno (diminution de la masse salariale), ils vont s y engouffrer. On vas rapidement assister a une montée en puissance de fonctionnels pointus capablent de modéliser correctement un SI, un base etc etc ..... Et cela ne prendra pas plusieurs décennies.

Bien sur, parce que actuellement, ce sont les devs qui compensent les lacunes (parfois). Mais cela peut évoluer.

C'est quoi, au final, un programme? C'est une suite de décisions formalisées. Plus le temps passe, et plus la surcouche technique est contournable. Mais reste le métier de base, l'algorithmique. Je décide de boucler sur les clients. Je décide que si le client a 60 ans, je lui envoie une carte d'anniversaire, avec une promo sur le nouveau produit. Je décide que le nouveau client a droit à 50€ en guise de bienvenue. JE décide, d'une manière suffisamment formalisée pour que la machine comprenne, et applique sans se gourer.

C'est toute la difficulté du travail de programmation. Transformer du "à peu près" linguistique que tout le monde peut comprendre(enfin, quand la MOA n'est pas trop branque) en "exactitude". Que les outils changent à l'avenir, je veux bien le croire. Que la formalisation change de forme, c'est bien possible.

Modéliser correctement, c'est penser à tout, et tout formaliser correctement. un développeur à peu près compétent, il prévoit le cas ou l'utilisateur idiot rentrer un montant en lettres parce-que ça fait partie de son métier. L'expert métier, lui, il pense à tout ce que ce montant doit faire, pas aux petits détails emmerdants de ce genre. C'est pour ça qu'il faut les deux. Je rappelle que le COBOL, une création de 1960, était déjà pensé pour que les comptables(donc des gens métier) et non pas des programmeurs puissent programmer. Ca ne s'est pas passé comme ça. Ce n'est pas un hasard.

[Glutinus]

le logiciel de paie des militaires Louvois..)

En même temps, si les règles étaient claires, c'est bien facile de dire "ça marche pas" si les specs couvrent pas au moins tous les cas connus...

[yento]

Y a du THF (Trading Haute Fréquence) en France, mais évidemment bien plus marginal qu'aux US par exemple. Très contrôlé par l'AMF, je ne sais pas à quel point ce dernier est moins des vendus que la SEC.
Peut-être que le scandale de la SG en 2010 (vol de code) peu de temps après Kerviel fait qu'on fait plus profil bas, peut-être plus que les capacités techniques...

Tout ce qui est "regulation" affecte les grosses banques, assurances et les exchanges.
En prop trading, quasiment aucune des regulations ne s'appliquent. C'est souvent de la petite entreprise, moins de 100 personnes, tres bas profil.

Les scandales de vols de code sont tous les ans. Le dernier gros récemment de l'autre de la rue https://www.bloomberg.com/news/featu...dge-fund-quant

Je me rend compte que je devrais faire un article sur le monde de la finance CIB, hedge fund, prop trading, HFT, arbitrage et autres.

[Marco46]

Tu as tout à fait raison,

mais là où il faut aujourd'hui 1000 jours homme pour mettre en place une nouvelle appli il n'en faudra peut être plus que 200, puisque la phase de réal telle qu'on la connait actuellement n'existera quasi plus. On aura des spécialistes qui feront un cahier de charge béton qui servira d'entrée pour la création du service désiré.

Maintenant, contrairement à Yolle, je n'y crois pas pour demain. Il reste beaucoup de chemin à parcourir pour arriver à ce résultat, du moins pour les applications complexes. Et puis il y aura forcément une réticence initiale à faire confiance à un code généré automatiquement à 100%, que ce soit pour des raisons de sécurité, etc, etc... Mais on y arrivera surement dans plusieurs décennies.

Mais non on y est déjà, tu veux juste pas admettre que le cahier des charges c'est le code source et le code généré automatiquement c'est l'exécutable. C'est aussi simple que ça.

On aura des programmes générés sur la base d'un langage naturel le jour où les IA seront des personnes pleines et entières avec une volonté propre et une culture générale et capables de comprendre un contexte. Donc c'est pas pour après-demain.

[Carhiboux]

Alors tu dois bosser dans une super boite si tu as des entrants de qualité.

Pour ma part, je suis plus habitué à recevoir des demandes post-it.

Oui, même quand il s'agit de projets à plusieurs centaines de jours.

Donc le jour où j'aurais des vraies expressions de besoin, complètes, exhaustives, on sera prêt pour la prochaine étape, mais déjà, rien que là dessus, on est loin de spécialistes que j'évoquais plus haut.

[Marco46]

La qualité des entrants reçu par le développeur ne change rien au fait que c'est lui qui produit la véritable spécification du programme : Le code source.

[MarieKisSlaJoue]

Alors tu dois bosser dans une super boite si tu as des entrants de qualité.

Pour ma part, je suis plus habitué à recevoir des demandes post-it.

Oui, même quand il s'agit de projets à plusieurs centaines de jours.

Donc le jour où j'aurais des vraies expressions de besoin, complètes, exhaustives, on sera prêt pour la prochaine étape, mais déjà, rien que là dessus, on est loin de spécialistes que j'évoquais plus haut.

C'est bien pour ça qu'on fait de l'agile, parce que les besoins envoyé ne serons jamais complet, exhaustives etc... Vu que les gens continue de faire leur demande sur des post-it et bien on à inventé des user story pour que ça tienne dessus et des tableaux de kaban pour les fixé au mur.

Pour la simplification du code (qui sont fait par des platefomes Low code comme K2 ou PowerApps) ça fait en majorité le taf, pour une bonne partie des applications métier ou de support (Note de frais, ticketing, reservation de salle, survey, la liste est infini.
Malheureusement ou heureusement on aura toujours besoin de code pour personnaliser certaine partie des process métier, pour s'interfacer avec le système custom développé par le stagiaire ou pas d'ailleurs.

Ensuite honnêtement l'informatique ce qui est souvent compliquer ce n'est pas d'écrire le code, c'est la configuration réseau/machine, appliquer les politiques de sécurité, se battre avec des proxy... Maintenant le déploiement de ressource c'est aussi du code et du JSON, bref on est pas au chômage tout de suite