Code de l'algorithme d'admission post-bac : Axelle Lemaire répond aux critiques
Et invite à voir le verre à moitié plein

Le , par Stéphane le calme, Chroniqueur Actualités
La secrétaire d’État au numérique et à l’innovation, Axelle Lemaire, a essayé d’endiguer les diatribes suite à la transmission sur format papier d’une partie du code source de l’ABP : « la Loi numérique n’était pas encore promulguée ! La transmission des codes sources est un progrès considérable, même s’il reste des marges ».


Si certains ont souligné un manque de volonté de coopérer de la part de l’État, notamment à cause du fait que choisir ce type de format implique de retaper des dizaines de pages de code et de s’assurer qu’aucune erreur de transposition ne sera insérée, d’autres se sont essayés à le déchiffrer (des scans ainsi qu’un cahier des charges ont été mis sur GitHub par des volontaires et pour les volontaires).

« Ce document donne pas mal de choses. A priori, il est présenté comme 'Document expliquant parfaitement l'algorithme'. Mais ce n'est absolument pas le cas. Il manque beaucoup trop de choses. Ce document nous dit comment les lycéens sont classés pour une filière donnée, mais ce n'est qu'un tiers ou la moitié des données du problème », a estimé un développeur. Pour un autre « envoyer du PL/SQL, sans documentation du schéma, au format papier, c'est clairement du foutage de gueule. C'en est même surprenant qu'ils n'aient pas enlevé les commentaires ».

À ceux qui estiment donc qu’il manque des indications à ce code pour comprendre comment fonctionne l’ensemble, la secrétaire d’État au numérique a rétorqué qu’elle voit le verre à moitié plein : « la nouvelle loi exige la lisibilité du code transmis. Oui il faut faire mieux. Mais combien de pays ouvrent leurs codes ? »


Source : Tweet Axelle Lemaire, Tweet Axel Lemaire


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Matthieu Vergne Matthieu Vergne - Expert confirmé https://www.developpez.com
le 21/10/2016 à 8:44
S'ils avaient vraiment la volonté de faire mieux, ils ne s'excuseraient pas en disant que d'autres pays font moins bien. Ils diraient ce qu'ils sont en train de faire pour aider davantage par la suite (fournir davantage de code ou de documentation, permettre de contacter des experts de l'algo pour demander plus de détails, etc.). Jusque là, je ne vois que des excuses vides de toute motivation à faire mieux. Donc pas de quoi remettre en cause le foutage de gueule.
Avatar de TJ1985 TJ1985 - Membre actif https://www.developpez.com
le 21/10/2016 à 8:52
En gros, ils répondent strictement à la demande, formulée par des idiots qui ne comprennent rien : Donnez-nous le code source de ce truc. Ils en rajoutent une louche en le passant par écrit.
Chacun de nous sait où est sensé savoir que ce n'est pas exactement ça qui était espéré (!), que c'est totalement inutile en l'absence du cahier des charges et du modèle. Mais bon, ça fait gagner du temps...
Avatar de Matthieu Vergne Matthieu Vergne - Expert confirmé https://www.developpez.com
le 21/10/2016 à 8:59
Citation Envoyé par TJ1985 Voir le message
Chacun de nous sait où est sensé savoir que ce n'est pas exactement ça qui était espéré (!), que c'est totalement inutile en l'absence du cahier des charges et du modèle. Mais bon, ça fait gagner du temps...
En fait, ce n'est pas qu'une question de bons sens : la demande initiale stipulait déjà de vouloir obtenir le code par e-mail ou, au pire, sur un CD. S'ils l'ont envoyé au format papier, c'est qu'ils ont voulu l'envoyer au format papier.
Avatar de neuneutrinos neuneutrinos - Membre habitué https://www.developpez.com
le 21/10/2016 à 11:47
Si j'étais médecin, pour voir si mon patient est en bonne santé, je ne regarderai uniquement sa main.
S'il se plaint que ce n'est pas assez suffisant, je lui dirait qu'il peut s'estimer heureux d'avoir un accès au soin !
S'il continue, je lui sortirai un bon Hakuna Matata avec un verre à moitié plein
J'adore cette logique !
Avatar de tbc92 tbc92 - Rédacteur/Modérateur https://www.developpez.com
le 21/10/2016 à 12:12
Je pense que le lycéen 'normal' se pose une seule question :
Je veux faire telle formation ; je sais que pour telle formation, il y a beaucoup de demandes, plus de demandes que de places disponibles.
Je mets bien entendu cette formation en 1er choix.
Quelle stratégie je peux adopter pour augmenter mes chances d'être accepté dans cette formation. Si je mets dans les autres choix des trucs qui sont aussi très demandés, est-ce que j'augmente mes chances d'avoir mon 1er choix.

Une petite FAQ sur le site https://www.admission-postbac.fr/index.php?desc=quoi permettrait de calmer le débat. A condition bien sûr que les réponses soient claires et vraies.

Dans un souci de transparence, ce serait bien aussi de publier différentes statistiques :
- X% des lycéens ont eu ce qu'ils ont mis en 1er choix, en 2nd choix ... etc
- Pour tel établissement, telle filière, il y avait tant de demandes, et les admis se répartissent de telle façon ...

Le code en lui-même n'est pas essentiel, le cahier des charges aurait été beaucoup plus utile.
Avatar de Matthieu Vergne Matthieu Vergne - Expert confirmé https://www.developpez.com
le 21/10/2016 à 12:55
Au contraire. Que le cahier des charges soit bien implémenté ou pas, au final c'est le résultat du code qui sera utilisé. Donc c'est bien le code qui importe, et non le cahier des charges. Ce dernier peut permettre de comprendre davantage, et de signaler des erreurs dans le code, mais l'accès au code est primordial.
Avatar de Marco46 Marco46 - Expert éminent https://www.developpez.com
le 21/10/2016 à 13:47
Citation Envoyé par Matthieu Vergne Voir le message
Au contraire. Que le cahier des charges soit bien implémenté ou pas, au final c'est le résultat du code qui sera utilisé. Donc c'est bien le code qui importe, et non le cahier des charges.
Ben quand même si le code n'implémente pas les règles décrites par le métier ...

Les specs sont indispensables. Le code tout seul ne permet pas de vérifier que l'algo est correctement implémenté ni qui les tests sont pertinents.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 21/10/2016 à 14:14
Citation Envoyé par Marco46 Voir le message
Ben quand même si le code n'implémente pas les règles décrites par le métier ...

Les specs sont indispensables. Le code tout seul ne permet pas de vérifier que l'algo est correctement implémenté ni qui les tests sont pertinents.
Toi, tu n'as jamais eu à refondre une application dont les specs avaient disparu. Depuis des décénnies(non, ceci n'est pas une exagération, un code écrit en 1972, dont la doc a été perdue dans les années 80, que j'ai refondu en 2008). Moi, on m'a dit : "tiens, ça marche comme du papier à musique, mais c'est inmaintenable - refais nous le même, mais propre et maintenable". La seule spec que j'avais était le nouveau format de sortie, mais sinon, le gros morceau, "comment calculer les données", je devais tout refaire à l'identique. Sans specs. J'ai trouvé quelques "merveilles", et même un vrai bug, qui trainait depuis des années, et qui aurait pu faire bobo, un jour.

Le code, c'est la vérité, dans le sens ou c'est ça qui tourne réellement. Les tests automatiques à coté, les commentaires, la doc, tout ça, ce sont des livrables secondaires permettant - normalement- d'éclairer le livrable principal. Mais c'est le livrable principal, le code, qui te dit ultimement ce qui se passe. Au final, pour l'étudiant qui veut comprendre son orientation, le cahier des charges n'est pas pertinent. C'est le code, le code seul, qui détermine si oui ou non il aura la Sorbonne en médiation culturelle, ou si il va se retrouver à Saint-Denis à faire de la sociologie des banlieues d'Oslo.
Avatar de Marco46 Marco46 - Expert éminent https://www.developpez.com
le 21/10/2016 à 17:05
Tu n'as pas compris ce que j'ai voulu dire.

Citation Envoyé par el_slapper Voir le message
Toi, tu n'as jamais eu à refondre une application dont les specs avaient disparu.
Je suis jamais tombé sur un donneur d'ordre assez con pour me donner un code vieux de plusieurs décades comme seul input en effet. Certains on tenté, mais discuter est la plupart du temps possible.

Après il y a specs et specs. Si tu as le soft sans spec mais un contact accessible qui comprend le besoin métier c'est tout à fait autre chose. Mais le code tout seul sans autre explication non jamais, et j'ajouterais que c'est tout à fait inacceptable. Jamais je n'accepterai une telle stupidité.

Citation Envoyé par el_slapper Voir le message
Au final, pour l'étudiant qui veut comprendre son orientation, le cahier des charges n'est pas pertinent. C'est le code, le code seul, qui détermine si oui ou non il aura la Sorbonne en médiation culturelle, ou si il va se retrouver à Saint-Denis à faire de la sociologie des banlieues d'Oslo.
Justement, si on lui dit que les critères pour aller Sorbonne c'est x === 3 && y === 5, ça serait bien que dans le code ça soit la même chose.

Je veux dire, admettons que ça soit une loi ou une directive de l'éducation nationale ou d'un ministère qui détermine les critères d'admissions, ce document a obligatoirement été traduite dans une spec permettant l'écriture du soft. Et si le soft a été écrit sans spec ça doit être précisé que c'est le développeur qui décide au doigt mouillé des critères d'admissions.

Je parle pas de specs techniques, je parle de spec fonctionnelles qui décrivent les fonctionnalités et les règles à appliquer.

Je sais bien que beaucoup de projets n'ont pas de specs, mais ça ne change rien qu'à un moment donné il y a une expression de besoin, qui peut être orale au pire, et qui est traduite en une spec, qui peut être un mail ou un bout de nape de resto au pire. Mais ces étapes sont incompressibles, quelles que soient leur qualité.

Et je dis donc que en publiant le code, ils doivent publier les specs qui vont avec, et s'ils n'en ont pas, ils doivent le dire et au minimum décrire le process qui sert d'input au développeur, sinon c'est les développeurs qui décident des critères d'admissions ce qui serait hallucinant.

Donc au final, je réitère, avoir le code est une chose, mais ça ne sert à rien si tu ne sais pas ce que devrait faire le code.
Avatar de Grogro Grogro - Membre expert https://www.developpez.com
le 21/10/2016 à 17:39
Citation Envoyé par Marco46 Voir le message
Je suis jamais tombé sur un donneur d'ordre assez con pour me donner un code vieux de plusieurs décades comme seul input en effet. Certains on tenté, mais discuter est la plupart du temps possible.
Probablement parce que tu ne fais pas partie du microcosme COBOL. A lire de temps à autre le vécu d'el slapper, je n'ai pas spécialement envie de le connaitre ce petit monde moi non plus.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 21/10/2016 à 21:02
Citation Envoyé par Grogro Voir le message
Probablement parce que tu ne fais pas partie du microcosme COBOL. A lire de temps à autre le vécu d'el slapper, je n'ai pas spécialement envie de le connaitre ce petit monde moi non plus.
La seule spécificité du COBOL dans ce cas, c'est son âge canonique. D'ici une vingtaine d'années, tous vos langages de jeunots seront soumis aux mêmes contraintes, pour les mêmes raisons.
Avatar de TJ1985 TJ1985 - Membre actif https://www.developpez.com
le 21/10/2016 à 21:48
Vous me faites bien rigoler les jeunots ! J'ai dû maintenir de code COBOL écrit par des brontosaures sans aucune formation informatique, ni aucun intérêt autre que financier à la chose. Des dizaines de milliers de lignes, sans aucun commentaire, avec des noms de variables type A1, TT... des Goto, des étiquettes genre "Premier", "Deux" etc.
Ca a été la pire période de ma carrière, mais la plus formative aussi. Et ça donne l'occasion de voir ce dont les utilisateurs ont vraiment besoin, pour pouvoir réécrire quelque chose de correct ensuite.
Mais c'était une période héroïque, qui demandait avant tout du talent et la volonté de faire. Aujourd'hui, on vous voit arriver avec vos peaux d'ânes toute fraîches, fringants et prêts à fiche par terre tout ce qui existe. Vous vous mettez à concevoir, décrire, spécifier, mais souvent vous réinventez la roue, vous résolvez glorieusement des problèmes qui n'en sont plus depuis des décennies simplement car vous n'avez que très peu d'expérience. Et c'est normal !
Mais évitez de monter sur vos grands chevaux et de proclamer urbi et orbi que vous êtes les seuls à savoir quoi et comment faire, à coup sûr quelqu'un a déjà réfléchi au problème qui vous occupe et souvent l'a déjà résolu. Et pour certains, vous avez de la chance de pouvoir choisir votre plateforme, mais évitez de proclamer trop fort que jamais vous ne ferez ceci ou cela, vous pourriez un jour avoir l'air d'un c...
Quant à moi, CAPS-11, CP/M, DOS, Windows 95-2000++, VMS, UNIX, OSX, Linux et j'en passe. BASIC, Pascal, C, Modula 2, COBOL, C++, divers scripting, DECForms, ACMS, SQL (RdB, Oracle, Sybase, ...) j'en passe et des meilleurs. Et j'ai même bricolé des trucs WEB HTML -CSS, qui tournent au quotidien depuis dix ans. Et aujourd'hui je joue avec SWIFT et commence SMS/nj pour les concepts qu'il implémente.
Moralité : Je suis un vieux con, mais j'ai aussi beaucoup de recul, alors croyez moi.
Avatar de Elepole Elepole - Membre éprouvé https://www.developpez.com
le 21/10/2016 à 23:38
[HS] Perso je suis prêt a apprendre le COBOL ou tous autre langage d'avant guerre, si j'ai accès a des outil adéquat gratuit. Malheureusement, j'ai des contrainte financière, et la ou je m'oriente pour l'instant je vois aucun retour sur investissement.[/HS]

Sinon, pour revenir au sujet, je trouve que c'est un jolie coup d'offuscation de code tous ça.
Avatar de TJ1985 TJ1985 - Membre actif https://www.developpez.com
le 22/10/2016 à 8:37
Citation Envoyé par Elepole Voir le message
[HS] Perso je suis prêt a apprendre le COBOL ou tous autre langage d'avant guerre, si j'ai accès a des outil adéquat gratuit. Malheureusement, j'ai des contrainte financière, et la ou je m'oriente pour l'instant je vois aucun retour sur investissement.[/HS]

Sinon, pour revenir au sujet, je trouve que c'est un jolie coup d'offuscation de code tous ça.
Non, ne te fais pas mal, COBOL ça eut payé mais ça paie plus. Et puis, ça tache les doigts, quand même !
Et sur le sujet, ils répondent bêtement à une question bête, c'est tout. Genre "tu veux du code source ? Tu vas en avoir !" Mais j'étais quand même sur le cul de voir leur système de nommage des variables. Ça, ça m'a renvoyé recta à ma tendre enfance...
Toutefois ça replace le débat à son vrai niveau. Aujourd'hui n'importe qui parle de "code" sans la moindre idée de ce que c'est ni de ce à quoi ça sert, finalement, même chose pour les algorithmes.
Je me verrais bien un jour faire livrer un plein carton d'algorithmes à un des journalistes qui en réclament à corps et à cris, genre caméra cachée...
Et sur le fond, on ne sait toujours pas comment est faite l'attribution, semble-t-il.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 22/10/2016 à 10:10
Citation Envoyé par TJ1985 Voir le message
Vous me faites bien rigoler les jeunots ! J'ai dû maintenir de code COBOL écrit par des brontosaures sans aucune formation informatique, ni aucun intérêt autre que financier à la chose. Des dizaines de milliers de lignes, sans aucun commentaire, avec des noms de variables type A1, TT... des Goto, des étiquettes genre "Premier", "Deux" etc.
(.../...)
Tiens, tu est passé au même endroit que moi?

Le pire, c'est qu'une ancienne m'a parlé des étiquettes A1-A2 comme une méthode ancienne mais structurée et éprouvée, ayant fait ses preuves. Surtout quand on a le label A121 avant le label A12, puis A123, suivi de A122..... Mais je suis sur que toi aussi tu as vu ça.

Non, sur le sujet, je crois qu'effectivement, le code source étant une grande inconnue pour tous les non-professionnels, c'est donc l'objet de grand fantasmes. J'ai tendance à dire qu'on bosse dans le domaine de l'invisible. Invisible parce que pour le non-initié, les arcanes sont inaccessibles. Invisible aussi, parce que même pour les initiés, quand il s'agit de découvrir un nouveau code source, ça ne se fait pas en claquant des doigts. Et parfois, on est bloqué quand même.

Donc, en réclamant le code source, les journalistes avaient raison : ils allaient avoir la vérité, ce qui tourne réellement. Mais ils avaient tort aussi, en croyant benoitement qu'il suffisait de lire le texte sacré pour avoir accès à tous les secrets des Dieux, sans effort. Même avec la spec, ils en auraient bavé, je suis sur : un spec est rarement limpide.
Avatar de Marco46 Marco46 - Expert éminent https://www.developpez.com
le 22/10/2016 à 10:45
Citation Envoyé par el_slapper Voir le message
La seule spécificité du COBOL dans ce cas, c'est son âge canonique. D'ici une vingtaine d'années, tous vos langages de jeunots seront soumis aux mêmes contraintes, pour les mêmes raisons.
Pas vraiment, il y a aussi l'amateurisme des personnes qui ont écrit les premiers codes qui n'a peut-être que peu évolué.

Depuis quelques années on a eu les design patterns, le TDD, l'Agile, les pratiques devops, etc .... Qui nous amènent doucement vers une professionnalisation de notre métier dont l'industrie et en particulier ses décideurs sont très immatures pour ne pas dire incompétents.

Tout ca pour dire que si vous pensez que votre expérience est universelle et reproductible pour les nouvelles générations vous vous trompez lourdement.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 22/10/2016 à 11:21
Citation Envoyé par Marco46 Voir le message
Pas vraiment, il y a aussi l'amateurisme des personnes qui ont écrit les premiers codes qui n'a peut-être que peu évolué.
Amateurisme, oui. Tout restait à inventer. Maintenant, est-ce que tous les petits jeunes font du code impeccable? Ce 'est pas mon impression.

Quand à "peu évolué", je ne suis pas sur de quoi tu parle, mais le code en question, est passé, chaque année pendant plus de trente ans, entre eu moins un dizaines de mains différentes, pour des modifications à tout va.

Citation Envoyé par Marco46 Voir le message
Depuis quelques années on a eu les design patterns, le TDD, l'Agile, les pratiques devops, etc .... Qui nous amènent doucement vers une professionnalisation de notre métier dont l'industrie et en particulier ses décideurs sont très immatures pour ne pas dire incompétents.
Outre la dichotomie programmeur = bon, décideur = méchant qui me parait sujette à caution(euphémisme), l'ampleur des projets moderne est bien plus grande que les bêtes chaines comptables avec quelques saisies transactionelles des années 70. Les outils dont tu parles sont de très bonnes choses, mais pour moi le problème n'a pas changé. LEs outils permettent de faire plus, alors on fait plus. Et, comme dans le temps, on ne s'arrête qu'aux frontières du supportable. Cette frontière a reculé, on est d'accord. Mais elle existe toujours, et tout le monde joue avec.

Évidemment, les détails seront différents. Mais tu crois qu'une boite qui se fait racheter trois fois en trente ans aura encore de la doc? Du code béton suivant toutes les normes?

Citation Envoyé par Marco46 Voir le message
Tout ca pour dire que si vous pensez que votre expérience est universelle et reproductible pour les nouvelles générations vous vous trompez lourdement.
Pas telle quelle, évidemment. Mais encore une fois, mon propos à ce sujet, c'était de dire que plus un code est vieux, et plus il est isolé par l'histoire de la boite qui tourne autour. Au début, il y a des specs, des dessins de chaine ou de base, tout un tas de trucs qui vont avec. Petit à petit, les gens sont mutés, les prestataires partent, la boite est rachetée, des serveurs sont perdus, les nouveaux ne savent même pas ou sont les docs, et on se retrouve avec le code. Seulement le code. Et c'est donc lui, et lui seul qui fait foi.

Alors évidemment, certains langages presque modernes permettent de faire de la doc à partir du code. C'est bien. C'est d'autant mieux que quand tout le reste à disparu, c'est tout ce qui reste. Et oui, c'est un progrès par rapport aux temps héroiques dont nous parlons. Mais ce PL/SQL n'est pas si vieux, et il n'est pas conçu pour être relu, de toute évidence. Et c'est tout ce qu'on a.
Avatar de Matthieu Vergne Matthieu Vergne - Expert confirmé https://www.developpez.com
le 23/10/2016 à 11:20
Citation Envoyé par Marco46 Voir le message
Ben quand même si le code n'implémente pas les règles décrites par le métier ...

Les specs sont indispensables. Le code tout seul ne permet pas de vérifier que l'algo est correctement implémenté ni qui les tests sont pertinents.
Effectivement, ce que le système est censé faire est important, car s'il ne le fait pas le système doit être modifié. Mais ce discours n'est valable que pour celui qui maintient le code. Ici, on est dans une optique de revue de code (i.e comprendre le code). S'il est effectivement possible de suggérer des améliorations, l'objectif premier ici est l'étude du code dans un but de compréhension, et non son amélioration (c'est le ministère qui en a la charge). C'est pourquoi ce besoin du cahier des charges devient secondaire.

Dans un autre contexte, tu aurais eu raison, mais ce n'est pas le cas ici.
Avatar de Marco46 Marco46 - Expert éminent https://www.developpez.com
le 24/10/2016 à 10:51
Citation Envoyé par el_slapper Voir le message
Amateurisme, oui. Tout restait à inventer. Maintenant, est-ce que tous les petits jeunes font du code impeccable? Ce 'est pas mon impression.
Je parlais des pratiques, elles n'existaient pas il y a 20 ans.

Est-ce que les jeunes font du code impeccable ? Certainement pas, mais les développeurs expérimentés n'ont plus aucune excuse de ne pas en faire, il y a tous les outils qu'il faut, toute la littérature nécessaire pour apprendre.

Citation Envoyé par el_slapper Voir le message
Quand à "peu évolué", je ne suis pas sur de quoi tu parle, mais le code en question, est passé, chaque année pendant plus de trente ans, entre eu moins un dizaines de mains différentes, pour des modifications à tout va.
Je veux dire que quand un développeur reste des décennies dans le même environnement technique, il ne progresse pas. Donc un développeur qui faisait du code dégueux il y a 20 ans et qui n'a fait aucun effort pour évoluer fera toujours du code dégueux 20 ans plus tard, probablement même pire.

L'expérience n'est pas mécaniquement un critère de qualité, c'est une condition.

Citation Envoyé par el_slapper Voir le message
Outre la dichotomie programmeur = bon, décideur = méchant qui me parait sujette à caution(euphémisme),
Je veux dire que la plupart des décideurs sont dangereux pour leurs propres projets parce qu'ils ne comprennent pas les impacts de leurs décisions de management parce qu'ils n'ont pas la moindre notion basique de génie logiciel. Par exemple un manager qui croit pouvoir accélérer la cadence sur un projet en retard en staffant du monde dessus, ou baisser la qualité pour augmenter la vélocité. Ce sont les décisions d'un incompétent.

Citation Envoyé par el_slapper Voir le message
l'ampleur des projets moderne est bien plus grande que les bêtes chaines comptables avec quelques saisies transactionelles des années 70. Les outils dont tu parles sont de très bonnes choses, mais pour moi le problème n'a pas changé. LEs outils permettent de faire plus, alors on fait plus. Et, comme dans le temps, on ne s'arrête qu'aux frontières du supportable. Cette frontière a reculé, on est d'accord. Mais elle existe toujours, et tout le monde joue avec.

Évidemment, les détails seront différents. Mais tu crois qu'une boite qui se fait racheter trois fois en trente ans aura encore de la doc? Du code béton suivant toutes les normes?
Si à chaque étape les gens font leur travail il n'y a aucun raison de perdre quoi que ce soit.

Citation Envoyé par el_slapper Voir le message
Pas telle quelle, évidemment. Mais encore une fois, mon propos à ce sujet, c'était de dire que plus un code est vieux, et plus il est isolé par l'histoire de la boite qui tourne autour. Au début, il y a des specs, des dessins de chaine ou de base, tout un tas de trucs qui vont avec. Petit à petit, les gens sont mutés, les prestataires partent, la boite est rachetée, des serveurs sont perdus, les nouveaux ne savent même pas ou sont les docs, et on se retrouve avec le code. Seulement le code. Et c'est donc lui, et lui seul qui fait foi.
Je m'en fous des raisons.

Un code seul est un code mort.

Comment fais-tu pour savoir que tu n'as pas créé de régression en l'absence de tests automatisé ? Comment sais-tu que le programme fait toujours ce qu'il est censé faire en l'absence de specs ET de tests ?

Se servir du code seul comme base c'est comme faire un 100m haie les yeux bandés. C'est stupide et dangereux.

Sinon pour en revenir à nos moutons le ministère de l'éducation nationale n'est pas une entreprise qui a été rachetée 3 fois non ?

Citation Envoyé par el_slapper Voir le message
Alors évidemment, certains langages presque modernes permettent de faire de la doc à partir du code. C'est bien. C'est d'autant mieux que quand tout le reste à disparu, c'est tout ce qui reste. Et oui, c'est un progrès par rapport aux temps héroiques dont nous parlons. Mais ce PL/SQL n'est pas si vieux, et il n'est pas conçu pour être relu, de toute évidence. Et c'est tout ce qu'on a.
Et c'est de la merde. Et ça montre le degré d'incurie qui règne dans la réalisation du SI de l'état et ça fait chier.
Avatar de Marco46 Marco46 - Expert éminent https://www.developpez.com
le 24/10/2016 à 10:53
Citation Envoyé par Matthieu Vergne Voir le message
Effectivement, ce que le système est censé faire est important, car s'il ne le fait pas le système doit être modifié. Mais ce discours n'est valable que pour celui qui maintient le code. Ici, on est dans une optique de revue de code (i.e comprendre le code). S'il est effectivement possible de suggérer des améliorations, l'objectif premier ici est l'étude du code dans un but de compréhension, et non son amélioration (c'est le ministère qui en a la charge). C'est pourquoi ce besoin du cahier des charges devient secondaire.

Dans un autre contexte, tu aurais eu raison, mais ce n'est pas le cas ici.
Comment ça revue de code ?

Relire le code sans pouvoir l'exécuter ça n'a absolument aucun intérêt.

Pouvoir l'exécuter sans le confronter au besoin métier réel ça n'a aucun intérêt (si tu exécutes un soft qui ne fait ce qu'il est censé faire quel intérêt ?)

L'intérêt de l'opendata c'est de permettre au public et aux entrepreneurs de pouvoir bâtir des services autour.
Avatar de Matthieu Vergne Matthieu Vergne - Expert confirmé https://www.developpez.com
le 24/10/2016 à 13:43
Citation Envoyé par Marco46 Voir le message
Comment ça revue de code ?

Relire le code sans pouvoir l'exécuter ça n'a absolument aucun intérêt.

Pouvoir l'exécuter sans le confronter au besoin métier réel ça n'a aucun intérêt (si tu exécutes un soft qui ne fait ce qu'il est censé faire quel intérêt ?)

L'intérêt de l'opendata c'est de permettre au public et aux entrepreneurs de pouvoir bâtir des services autour.
Encore une fois, ton problème est que tu te focalises sur un type de travail (une perspective, un besoin, une façon de faire) spécifique alors que ce n'est pas le seul possible, et en l'occurrence pas celui qui nous intéresse ici.

Certes, pouvoir exécuter le code est un atout, mais en rien une nécessité. Ce n'est pas parce qu'on es incapable de le lancer qu'on es incapable de l'analyser. Dire cela c'est mettre au rabais l'expertise humaine. N'oublies pas que le code est écrit par un humain. De toute évidence cela ne pourrait pas se faire si le code en lui-même ne pouvais pas être compris autrement que par son exécution. Par expérience, je n'ai pas besoin d'exécuter un code Java pour me rendre compte qu'un code est mal écrit et pour y trouver des fautes. Je participe a quelques projets open source et rien que de lire les commits me permet en général de déceler des erreurs ou des défauts qu'on aurait difficilement vu a l'exécution (par manque de tests). Quand tu n'a ni tests ni environnement d'exécution, et bien tu fais sans, tout simplement. Dans le cadre de la recherche, analyser un code à la main est un requis, car son exécution ne raconte pas tout. Et c'est bien un contexte de recherche qu'on vise ici : les demandeurs veulent connaître la formule, et non pas exécuter le programme chez eux.

Bref, arrête de penser qu'il n'y a qu'une seule bonne façon de faire ou d'interpréter les choses. Tu t'enlèves plus d'éléments de compréhension que tu ne t'en rajoutes.
Avatar de Luckyluke34 Luckyluke34 - Membre émérite https://www.developpez.com
le 24/10/2016 à 13:55
Citation Envoyé par TJ1985 Voir le message
Vous me faites bien rigoler les jeunots ! J'ai dû maintenir de code COBOL écrit par des brontosaures sans aucune formation informatique, ni aucun intérêt autre que financier à la chose. Des dizaines de milliers de lignes, sans aucun commentaire, avec des noms de variables type A1, TT... des Goto, des étiquettes genre "Premier", "Deux" etc.
Ca a été la pire période de ma carrière, mais la plus formative aussi. Et ça donne l'occasion de voir ce dont les utilisateurs ont vraiment besoin, pour pouvoir réécrire quelque chose de correct ensuite.
Mais c'était une période héroïque, qui demandait avant tout du talent et la volonté de faire. Aujourd'hui, on vous voit arriver avec vos peaux d'ânes toute fraîches, fringants et prêts à fiche par terre tout ce qui existe.
Bref, continuons à faire faire de la bouse par des gens pas formés en compliquant inutilement la vie de ceux qui vont maintenir le code, parce que "c'est formateur" ?
Avatar de Grogro Grogro - Membre expert https://www.developpez.com
le 24/10/2016 à 14:07
Citation Envoyé par el_slapper Voir le message
La seule spécificité du COBOL dans ce cas, c'est son âge canonique. D'ici une vingtaine d'années, tous vos langages de jeunots seront soumis aux mêmes contraintes, pour les mêmes raisons.
Tu penses que nos langages à la mode vivront aussi longtemps que le vénérable COBOL ? Dans 25 ans, on fera toujours du java, du c#, du php ?

Le COBOL ça parait immortel ce langage. Il nous enterrera tous.
Avatar de Luckyluke34 Luckyluke34 - Membre émérite https://www.developpez.com
le 24/10/2016 à 14:37
Citation Envoyé par Matthieu Vergne Voir le message
Citation Envoyé par Marco46 Voir le message
...
Encore une fois, ton problème est que tu te focalises sur un type de travail (une perspective, un besoin, une façon de faire) spécifique alors que ce n'est pas le seul possible, et en l'occurrence pas celui qui nous intéresse ici.

Certes, pouvoir exécuter le code est un atout, mais en rien une nécessité. Ce n'est pas parce qu'on es incapable de le lancer qu'on es incapable de l'analyser. Dire cela c'est mettre au rabais l'expertise humaine. N'oublies pas que le code est écrit par un humain. De toute évidence cela ne pourrait pas se faire si le code en lui-même ne pouvais pas être compris autrement que par son exécution. Par expérience, je n'ai pas besoin d'exécuter un code Java pour me rendre compte qu'un code est mal écrit et pour y trouver des fautes. Je participe a quelques projets open source et rien que de lire les commits me permet en général de déceler des erreurs ou des défauts qu'on aurait difficilement vu a l'exécution (par manque de tests). Quand tu n'a ni tests ni environnement d'exécution, et bien tu fais sans, tout simplement. Dans le cadre de la recherche, analyser un code à la main est un requis, car son exécution ne raconte pas tout. Et c'est bien un contexte de recherche qu'on vise ici : les demandeurs veulent connaître la formule, et non pas exécuter le programme chez eux.
Pour réconcilier les deux points de vue, il existe aussi des techniques pour explorer de manière automatisée le comportement d'une application. Property based testing permet, par exemple, de formuler des théories sur celle-ci et de les vérifier en la bombardant de valeurs en entrée et en vérifiant les sorties.

J'aurais tendance à partir là-dessus en posant des théories par rapport au contexte comme les noms des variables, des tables, etc (qui sont quand même bien pourris) et à ce qu'on connait déjà sur l'algo.
Avatar de Grogro Grogro - Membre expert https://www.developpez.com
le 24/10/2016 à 15:08
Citation Envoyé par Luckyluke34 Voir le message
Pour réconcilier les deux points de vue, il existe aussi des techniques pour explorer de manière automatisée le comportement d'une application. Property based testing permet, par exemple, de formuler des théories sur celle-ci et de les vérifier en la bombardant de valeurs en entrée et en vérifiant les sorties.

J'aurais tendance à partir là-dessus en posant des théories par rapport au contexte comme les noms des variables, des tables, etc (qui sont quand même bien pourris) et à ce qu'on connait déjà sur l'algo.
Ca m'intéresse beaucoup. Peux-tu nous en dire plus ?
Avatar de Luckyluke34 Luckyluke34 - Membre émérite https://www.developpez.com
le 24/10/2016 à 17:50
Citation Envoyé par Grogro Voir le message
Ca m'intéresse beaucoup. Peux-tu nous en dire plus ?
Le standard c'est QuickCheck en Haskell mais ça a été porté vers plein d'autres langages fonctionnels comme FsCheck en F#. En cherchant bien, on doit pouvoir trouver des bibliothèques *Check pour des langages OO style Java.

En gros, tu poses tes théorèmes - les propriétés de ton algo que tu souhaites tester. Ca pourrait être (je dis n'importe quoi) :

Code : Sélectionner tout
1
2
3
4
5
Sur une formation post-bac donnée, un élève ne peut pas avoir un rang plus bas que le nombre total d'élèves qui candidatent.

Sur une formation post-bac donnée, deux élèves ne peuvent pas avoir le même rang.

Un élève a forcément une réponse positive à au moins deux formations post-bac.
Concrètement, dans le code, ça donne des fonctions qui prennent en paramètre toutes les données d'entrée nécessaires à ton algo. Dans le corps de la fonction, il y a une assertion (la propriété) qui renvoie un booléen, un peu comme dans un test unitaire traditionnel. L'assertion contient un appel de l'algo.

QuickCheck va :

  • Lancer le test un nombre arbitrairement élevé de fois en balançant des données aléatoires en input

  • Lorsqu'il trouve des données pour lesquelles le théorème ne tient pas (ton assertion est fausse), te les afficher

  • Faire un shrink sur ces cas d'échec, c'est à dire chercher à trouver la plus petite donnée d'entrée qui pète quand même le théorème. La notion de plus petite est définie par type de donnée : par exemple, une liste à 1 élément est plus petite qu'une liste à deux éléments, etc. Tu peux définir tes propres shrinkers pour test types à toi.


De base, des générateurs aléatoires pour pas mal de trucs (scalaires, listes) sont fournis mais tu peux définir les tiens.
Avatar de Matthieu Vergne Matthieu Vergne - Expert confirmé https://www.developpez.com
le 24/10/2016 à 19:19
Citation Envoyé par Luckyluke34 Voir le message
Pour réconcilier les deux points de vue, il existe aussi des techniques pour explorer de manière automatisée le comportement d'une application. Property based testing permet, par exemple, de formuler des théories sur celle-ci et de les vérifier en la bombardant de valeurs en entrée et en vérifiant les sorties.

J'aurais tendance à partir là-dessus en posant des théories par rapport au contexte comme les noms des variables, des tables, etc (qui sont quand même bien pourris) et à ce qu'on connait déjà sur l'algo.
Oui mais là encore, ça s'appuie sur l'exécution. Si tu peux pas exécuter ton code, comme c'est le cas ici, tu ne peux faire aucun test automatique. Donc tes property faudra les chercher à la main en analysant la syntaxe du code. Éventuellement tu peux faire de l'analyse statique, ça au moins ça demande juste d'avoir le code, pas de l'exécuter.
Avatar de Luckyluke34 Luckyluke34 - Membre émérite https://www.developpez.com
le 25/10/2016 à 11:47
Citation Envoyé par Matthieu Vergne Voir le message
Si tu peux pas exécuter ton code, comme c'est le cas ici
Pourquoi on ne pourrait pas ? Il y a même quelqu'un qui a fait un simulateur en Python.

Citation Envoyé par Matthieu Vergne Voir le message
Donc tes property faudra les chercher à la main en analysant la syntaxe du code.
Oui, c'est ce que je voulais dire par "poser des théories par rapport au contexte". Il faut un minimum de lecture du code pour partir avec des property qui ne sont pas trop déconnantes.

Mais si tu te bases entièrement sur la lecture du code pour déterminer des règles fonctionnelles sans te laisser la possibilité de l'exécuter pour vérifier tes hypothèses, c'est quand même assez casse-gueule.
Avatar de Matthieu Vergne Matthieu Vergne - Expert confirmé https://www.developpez.com
le 25/10/2016 à 16:37
Citation Envoyé par Luckyluke34 Voir le message
Pourquoi on ne pourrait pas ? Il y a même quelqu'un qui a fait un simulateur en Python.
Dans l'absolu, tu peux toujours exécuter si tu rajoute tout ce qui manque par toi-même. Mais cela demande un investissement et ne correspond pas forcément à ce qui se fait réellement. Le code n'a pas été fourni pour être exécuté, c'est un fait, et c'est sur cette base que je prend la perspective d'un code "non exécutable". Faut pas oublier que mon propos est que ce n'est pas parce qu'on ne peut pas l'exécuter qu'on ne peut rien en faire.

Citation Envoyé par Luckyluke34 Voir le message
Oui, c'est ce que je voulais dire par "poser des théories par rapport au contexte". Il faut un minimum de lecture du code pour partir avec des property qui ne sont pas trop déconnantes.

Mais si tu te bases entièrement sur la lecture du code pour déterminer des règles fonctionnelles sans te laisser la possibilité de l'exécuter pour vérifier tes hypothèses, c'est quand même assez casse-gueule.
Je ne dis pas le contraire, mais les analyses statiques et dynamiques sont complémentaires, y'en a pas une meilleure que l'autre. Les deux sont importants. L'exécution n'apporte pas tout.
Avatar de TJ1985 TJ1985 - Membre actif https://www.developpez.com
le 25/10/2016 à 18:54
Le sujet était assez simple : Nous voulons comprendre comment est faite la répartition des postulants à certaines formations en fonction de leurs souhaits, des places disponibles et des résultats qu'ils ont obtenu aux examens qu'ils ont passé.
La formulation a été faite par des gens qui n'y connaissent rien, et qui ont donc demandé le code source de l'algorithme chargé du boulot. Chacun de nous je pense sera d'accord que ça ne veut rien dire et qu'il faut avoir du temps à perdre pour partir du code pour remonter aux règles, surtout si on ne dispose pas du modèle.
Nous pouvons donc considérer que :
- La question est posée par des gens incompétents.
- Ils se sont fait rouler dans la farine.
- Le sujet doit être assez chaud chez les gens en charge de "l'algorithme".
- Si il n'y avait pas de loup, tout ça serait sans problème sur la place publique.
Après cela, il serait bon de se demander ce qu'on veut vraiment, soit comprendre ces bouts de code indigestes, soit comprendre ce qu'on a voulu implémenter. Je penche pour la deuxième proposition, car à partir de là nous pouvons toujours nous construire une solution propre, avec son jeu de test, et la proposer à froid.

En conclusion : Il semble que les gens en charge de l'informatique dans certaines instances officielles doit être une sacrée chasse gardée - et potentiellement une sacrée pétaudière - pour qu'il soit impossible d'obtenir une réponse sensée à une question sommes-toutes très simple.
Vous n'êtes pas d'accord ?
Avatar de Luckyluke34 Luckyluke34 - Membre émérite https://www.developpez.com
le 26/10/2016 à 14:18
Citation Envoyé par TJ1985 Voir le message
Après cela, il serait bon de se demander ce qu'on veut vraiment, soit comprendre ces bouts de code indigestes, soit comprendre ce qu'on a voulu implémenter. Je penche pour la deuxième proposition, car à partir de là nous pouvons toujours nous construire une solution propre, avec son jeu de test, et la proposer à froid.
Du coup, on fait comment ? On fait confiance à l'administration pour produire une description en français de "ce qu'on a voulu implémenter" qui 1/ soit intelligible et 2/ corresponde vraiment à ce que fait l'algo ? C'est bien parce qu'on a des doutes sur sa capacité de fournir l'un et l'autre que le code source a été demandé. Retour à la case départ.

De plus, peut-être que les demandeurs seraient intéressés par un recensement de bugs ou de propriétés peu évidentes de l'algo qui vont ajouter de l'eau à leur moulin. Ce genre de trucs se détecte rarement juste "en comprenant ce qu'on a voulu implémenter". Il faut faire tourner la fonction.
Avatar de danyclassique danyclassique - Membre du Club https://www.developpez.com
le 29/10/2016 à 9:18
Je pense a mon humble avis, qu'il y a une grande différence entre déchiffrer un code sans Specs ou autre ,quand il s'agit d'un code cobol ou code inline et quand il s'agit d'un code orienté object comme par exemple, c# ou c++ , je parle pas de codes style ,un project qui contient 27 classes mais bien des solutions qui contiennent au moins 77 projects ,et bien sur, avec une exploitation de la poo a grande échelle ainsi que de l'interopatibilite et pas des classes dérivées a deux niveaux et interface de décoration mais "d'utilité obligatoire".
Avatar de grunt2000 grunt2000 - Membre confirmé https://www.developpez.com
le 22/07/2017 à 22:54
Entre Anacrime dont les suggestions provoquent l'arrêt de Murielle Bolle et le suicide du juge Lambert dénonçant spécifiquement ce logiciel,
et APB qui laisse sur le carreau encore 67 000 bacheliers tout en en ayant affecté un grand nombre n'importe où ou en n'importe quoi,
je crois que nous sommes devant des monuments d'informatique imbécile dont nous devons prendre la mesure.

Parce qu'ils nous montrent à quel point notre art peut être dévoyé et produire le monde le plus abominable quand il est aux mains d'incompétents, de négligents, et de trop cupides.
Un monde devenu logiciellement injuste et brutal.
On ne peut qu'imaginer combien des jeunes de toutes filières sont maintenant désemparés et ne savent pas comment faire face à quelque-chose d'inhumain, comme ces ordinateurs et IA fous de romans d'anticipation, et qui en plus d'être visiblement raté n'explique à personne (et même pas à eux, ses victimes) son fonctionnement, ses choix.
Avatar de Bubu017 Bubu017 - Membre averti https://www.developpez.com
le 24/07/2017 à 15:48
Mouais enfin c'est facile d'accuser le logiciel. C'est toujours la faute de l'informatique et jamais de l'interface chaise-clavier.
Offres d'emploi IT
Développeur Java à Nice (H/F)
SMILE - Provence Alpes Côte d'Azur - Nice (06000)
Ingénieur/Chef de projet analyste produit H/F
GPConseil - Rhône Alpes - Lyon (69000)
Business Analyst M/F
Michael Page - Nord Pas-de-Calais - Lillers (62190)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil