@Par Mycroft (xxx.xxx.xxx.114) 6 septembre 17:10
Vous dites : « Pour vous, la recherche en info, c’est juste des logiciels ? » [...]
Ah d’accord votre sujet c’est la recherche en info ?
Bien sûr, la recherche en info peut être la recherche d’algorithme qui lui peut se faire à la main sans ordinateur pour être précis.
Le sujet du jour est tout simplement le travail normal pas les cas particuliers comme la recherche qui suit une autre filière.
La recherche est un investissement : pour faire court, la rentabilité n’est pas la priorité... stricto sensu...
[mais elle est sous entendue]

Vous dites : "Vous savez que beaucoup de problématique d’ordonnancement, de protocole de sécurité, de modélisation informatique, de mise en place de langage de programmation sont tout autant des domaines sur lesquels il faut travailler ?" [...]
Je suis une personne qui s’intéresse à tout comme à l’informatique.
Donc, oui je le sais : les problèmatiques de sécurité sont une passion pour moi.
Avec Linux vous utilisez le framework iptables par exemple pour réaliser une sécurité plus efficace, n’est-ce pas ?
Rien que dans le domaine de l’informatique on peut faire des thèses sur la cryptologie :
« Les courbes elliptiques ont de nombreuses applications » [...]« en cryptologie dans le problème de la factorisation des entiers ou pour fabriquer des codes performants » [...]

(source : Courbe elliptique - Wikipédia)
Nous sommes en phase ? 

La recherche dont je parle c’est essentiellement la création d ’un logiciel ou application...
Mais si vous tenez à parler de recherche pure, seules les grosses structures peuvent se le permettre...

Vous dites : « Quand à la rentabilité immédiate de la recherche... c’est un non sens. » [...]
Dans mon discours, la rentabilité « immédiate » n’est pas un non sens car il s’agit de se poser la seule question qui se pose pour tout décideur d’un centre de profit :
Quel est le coût d’opportunité ?

Vous dites : « Vous ne semblez pas y connaitre grand chose. Les normes sont des choses facilement contournable » [...]
C’est vous qui n’y connaissez rien.
Tout dépend de votre contrat. Si votre contrat est laxiste, et j’en ai déjà vu, alors oui vous pouvez proposer à la limite n’importe quoi persone ne pourra vous critiquer.
Le client vous insultera et c’est tout, s’il a fait l’erreur de signer ou l’inverse.

Vous dites : « Les normes de codage ne sont pas faites par des gens qui connaissent vraiment le terrain » [...]
Si vous vous laissez marcher sur les pieds, il est évident que vous aurez ce genre de soucis.
Les normes de codages sont normalement le fait du MOE pas du MOA.
Mais par contrat le MOA peut exiger du MOE une norme précise que vous ne pouvez évidemment pas refuser... si vous êtes le MOE... 

Vous dites : "Elles sont par moment très lourdes et inutilement contraignantes, par moment extrèmement laxiste et permettent des choses immaintenable. Définir des normes efficace serait un bon sujet de recherche justement" [...]
inutilement contraignantes ? Pour caricaturer, un checklist est inutile aussi ?
Les normes de codages et de nommages sont utiles dès l’instant où on veut prévoir la maintenance d’un logiciel par exemple.
La maintenance est impossible s’il n’y a pas un minimum de normalisation.
Il est vrai que je me souviens d’un directeur [ssii] qui me disait qu’il avait du mal à faire respecter les normes parce qu’il était en fait surbooké [pénurie de compétences].
Mais ce que lui n’a pas compris c’est que si une maintenance était nécessaire, ce serait impossible de le confier à des inconnus : il faut appeler LE développeur concerné.

Vous dites : "vous parlez de respect du cahier des charges, mais ces derniers ne sont pas fait par des techniques entre technique, mais souvent par des ex-technique ou par de mauvais technique qu’on a sortie du technique pour réduire leur capacité de nuisance" [...]
 
Désolé mais pour réussir, il faut un excellent cahier des charges.
Quelque soit le domaine, j’ai déjà lu de bon cahier des charges, et comme par hasard ce sont des entreprises compétentes qui les sortent.
De plus, tout roule comme sur des roulettes.
Mais lorsque ce sont des incompétents c’est un vrai foutoir...
Et dans le domaine de l’informatique le problème n’est pas spécifiquement le cahier des charges mais l’impossibilité pour le client de traduire dans un language compréhensible pour un informaticien son besoin.
Je précise que ce n’est pas le client qui est un incapable mais plutôt le technicien (l’informaticien) [le spécialiste du cahier des charges] qui n’arrive pas à poser les bonnes questions.
Je ne parle même pas de le technicien (l’informaticien) qui ne maîtrise pas le process du client, à supposer que ce soit son process que l’on veut modéliser par exemple.
Le cahier des charges dans ce dernier cas, devient donc bancale...
Et le chef de projet qui reçoit le cahier des charges final souvent ne l’apprend que trop tard...

 
Cordialement

Leo Le Sage
(Personne respectueuse de la différence et de la pluralité des idées)