Discussion :

[Patrick Ruiz]

Quelles sont les habitudes à avoir pour parvenir à mettre sur pied d’excellents logiciels ?
Voici une liste inspirée du livre « 66 façons dont les experts pensent »

De façon indépendante du domaine dans lequel on œuvre, combiner expérience et capacités innées permet de se démarquer de ses pairs. Dans la filière de la programmation informatique, c’est la même réalité. En fait, il s’agit des deux ingrédients à mettre ensemble pour aboutir à ce que l’on peut appeler le « programmeur expert. » Il y a seulement que faire mention de l’expérience et des capacités innées ne permet pas de savoir comment ce dernier aborde les diverses tâches qui sont les siennes au quotidien ; en d’autres termes, quelles sont les habitudes sur lesquelles il s’appuie pour une meilleure conception de logiciels. Dans un article paru il y a peu, deux auteurs proposent une liste inspirée de leur livre intitulé « 66 façons dont les experts pensent. »

1. Impliquer les utilisateurs

Les experts connaissent très bien les utilisateurs. Ils impliquent délibérément les utilisateurs dans le processus de conception, les étudient, leur parlent, les invitent à tester des conceptions intermédiaires et leur demandent même de jouer un rôle actif dans l'équipe de conception.

Pourtant, les experts ne prennent pas tout ce que les utilisateurs disent pour argent comptant. Ils se rendent compte des limites potentielles, car la pensée des utilisateurs est souvent colorée par les expériences actuelles. Les experts regardent au-delà de ce que les utilisateurs demandent, vers ce dont ils ont réellement besoin.

2. Mettre au point d’élégantes abstractions

Alors que tous les développeurs créent des abstractions, les experts les conçoivent. Une bonne abstraction met en évidence ce qui est important, à la fois dans ce qu'elle fait et comment elle le fait. À travers une seule lentille, il communique le problème qu'il résout et la mécanique de sa solution.

Les experts ne se contentent pas de n'importe quelle abstraction, ils cherchent délibérément des abstractions élégantes à travers lesquelles des structures complexes peuvent être introduites, comprises et référencées de façon efficace.

3. Focaliser sur l’essentiel

Chaque problème de conception tourne autour d'un ensemble de considérations essentielles qui doivent être comprises et injectées dans la solution pour qu'elle puisse résoudre le problème avec succès. Cette essence peut être perturbatrice : les changements dans le noyau modifient de façon radicale les décisions périphériques qui doivent être prises. Les experts concentrent d'abord leurs efforts sur l'essence et retardent les efforts de conception à la périphérie.

4. Simuler de façon continue

Les experts imaginent comment un design fonctionnera en simulant des aspects du logiciel envisagé et comment ses différentes parties supportent une variété de scénarios. Lorsqu'ils travaillent avec d'autres personnes, les experts passent régulièrement en revue un design en donnant, à haute voix, des détails sur son fonctionnement étape par étape. Lorsqu'ils sont seuls, ils simulent de façon mentale, en testant le design de façon répétée.

5. S’inspirer de l’existant

De la même manière que les architectes se promènent dans les villes pour examiner et s'inspirer des bâtiments existants, les experts en logiciels examinent les détails de la conception d'autres logiciels. Ils le font souvent en réponse à un défi particulier auquel ils sont confrontés, mais il leur arrive de passer du temps à regarder autour d'eux simplement pour enrichir leur répertoire de solutions à utiliser à l'avenir.

6. Proposer des modèles alternatifs de l’espace problème


Les experts prennent souvent du recul par rapport au problème énoncé et l'envisagent de manière plus large, en cherchant d'autres moyens de cerner le problème. Ils peuvent changer de direction en concevant à nouveau l'espace du problème ou en abordant un problème différent dans le même espace. Ils choisissent de façon intentionnelle des objectifs quelque peu différents du problème de conception d'origine, car cela leur permet de comprendre où se situe le vrai problème ou comment surmonter les principaux obstacles.

7. Voir les erreurs comme des opportunités

Le processus de conception implique régulièrement des erreurs : des choses qui vont mal, des malentendus, des obstacles, des mauvais virages, des problèmes qui font surface. Plutôt que de craindre l' erreur, les experts la considèrent comme une opportunité. Ils l'acceptent comme une partie inhérente du processus et prennent le temps d'explorer à la fois l'échec et le contexte qui l'entoure. Comprendre ce qui s'est passé révèle souvent un aperçu du problème ou de la solution

8. Bien prendre en compte les limites

Bien qu'il soit naturel de se concentrer sur ce qu'un design doit accomplir, les experts passent aussi du temps à réfléchir à ce qu'un design n'est pas destiné à faire. En articulant et en considérant les limites, ils découvrent où ils sont sur et sous-dimensionnés.

Marian Petre et Andre Van Hoek proposent là un sous-ensemble des habitudes (8 sur 66 au sein de leur livre) à avoir pour parvenir à concevoir d’excellents logiciels. Sur le plan du fond, il faut dire qu’il est assez sommaire, ce qui pourrait laisser place à diverses interprétations. Par exemple, sans plus d’éclaircissements, le troisième point peut laisser penser qu’ils suggèrent de s’arrimer à une approche de développement ascendante dans laquelle on écrit les fonctionnalités de base avant même de penser à l’interface. En fait, cet état de choses est même de nature à suggérer des éléments additifs à cette liste : la précision ; l’on pourrait faire la proposition d’extension de liste « l’expert doit s’exprimer avec précision », mais sans plus pour rester sur le fil conducteur des auteurs. En fait, le sujet interpelle et mobilise l’attention d’intervenants de la filière. De façon générale, c’est le volet expérience sur lequel les développements portent puisqu’y faire référence c’est aussi passer en revue des habitudes et principes qu’un tiers met en application au travail pour atteindre ses objectifs. Jacob Kaplan-Moss – l’un des principaux contributeurs Django – a d’ailleurs formulé un avis allant dans ce sens il y a quelques années en soulignant que « la programmation n’est pas une passion ni un talent, ce n’est qu’un ensemble de compétences que tout le monde peut apprendre. » Autrement dit, la capacité à mettre sur pied d’excellents logiciels s’acquiert en passant par l’acquisition de certaines habitudes et principes.


Source : MIT PRESS

Et vous ?

Que pensez-vous de cette liste ? Vous satisfait-elle sur le plan du fond ?

Quels sont les éléments qu’on pourrait y ajouter ou qui devraient ne pas y paraître ?

Quelles sont les habitudes sur lesquelles vous vous appuyez au quotidien pour parvenir à concevoir d'excellents logiciels ?

Voir aussi :

Qu'est-ce qui fait un bon programmeur ? Un senior liste cinq caractéristiques d'un bon programmeur

Faut-il éliminer le mythe du programmeur génie ? Selon un sénior, « la plupart des gens sont moyens » et cela n'est pas grave

Le talent et la passion suffisent-ils pour faire un bon développeur ? Les créateurs de Django, PHP et Rails n'étaient pas des passionnés du code

Tout le monde ne peut pas devenir développeur, il faut d'abord disposer de certains prérequis

[Garvelienn]

Autre :
Mettre à l'écart les commerciaux/marketeux de la décision et des choix en les remplaçant par les utilisateurs finaux. Ce qui rejoint le premier point de l'article

[requinham]

faudra prendre le temps de bien réfléchir la stratégie business et l'architecture.

[transgohan]

1. Impliquer les utilisateurs

Les experts connaissent très bien les utilisateurs. Ils impliquent délibérément les utilisateurs dans le processus de conception, les étudient, leur parlent, les invitent à tester des conceptions intermédiaires et leur demandent même de jouer un rôle actif dans l'équipe de conception.

Pourtant, les experts ne prennent pas tout ce que les utilisateurs disent pour argent comptant. Ils se rendent compte des limites potentielles, car la pensée des utilisateurs est souvent colorée par les expériences actuelles. Les experts regardent au-delà de ce que les utilisateurs demandent, vers ce dont ils ont réellement besoin.

Je ne vois pas le rapport avec de l'expertise technique en informatique...
C'est de l'expertise de commercial dont on parle ici (faut bien que son métier serve à quelque chose ).
Impliquer le client, savoir exactement ce qu'il veut, tout ceci pour ne pas le décevoir et être certain de vendre au mieux le produit.
Certes l'expert en informatique sera impliqué dans le processus mais il n'en est pas responsable.

De toute façon dans 80% des cas ce n'est pas l'expert en informatique qui voit le client donc...

Sur le plan du fond, il faut dire qu’il est assez sommaire

Je dirai même que c'est juste de la logique.
Or la logique c'est un peu la base de notre métier.

[sergio_is_back]

Je ne vois pas le rapport avec de l'expertise technique en informatique...
C'est de l'expertise de commercial dont on parle ici (faut bien que son métier serve à quelque chose ).

Tout dépend de ce que tu vends : du logiciel sur étagère, du développement personnalisé (basé sur un soft existant) ou du développement à façon. C'est pas pareil !

Impliquer le client, savoir exactement ce qu'il veut, tout ceci pour ne pas le décevoir et être certain de vendre au mieux le produit.
Certes l'expert en informatique sera impliqué dans le processus mais il n'en est pas responsable.

Si : "l'expert informatique" est responsable de ce qu'il livre auprès du client (enfin c'est comme ça chez nous)

De toute façon dans 80% des cas ce n'est pas l'expert en informatique qui voit le client donc...

C'est bien le problème dans certaines boites, les commerciaux chiffrent et vendent sans avoir pris l'avis des développeurs du coup à l'arrivée ça ne colle pas...
Pour les gros projets chez nous on envoi toujours un développeur et parfois même une deuxième personne du BE avec le commercial pour avoir toutes les billes pour le chiffrage et encore ça nous arrive de nous tromper...

Je dirai même que c'est juste de la logique.
Or la logique c'est un peu la base de notre métier.

La logique de certains est parfois bien déroutante...

[Nebulix]

C'est quoi, un logiciel "excellent" ?
Deux réponses extrêmes :
Un logiciel qui fait le boulot sans problème
Un logiciel qui oblige le client à dépenser une fortune en maintenance, formation, etc.
(heureusement pour le premier cas, il y a les maj de Windows)

[transgohan]

Si : "l'expert informatique" est responsable de ce qu'il livre auprès du client (enfin c'est comme ça chez nous)

J'en comprends qu'il est responsable en cas de cahier des charges que le client ne reconnait plus une fois signé non ?

Car sinon, c'est de la logique, on est bien d'accord qu'on est responsable en cas d'écart avec le cahier des charges sur la livraison.

[sergio_is_back]

J'en comprends qu'il est responsable en cas de cahier des charges que le client ne reconnait plus une fois signé non ?

Le cahier des charges est parfois réduit à sa plus simple expression. Normalement c'est le rapport de spécifications logicielles qui fait foi (l'analyse si tu préfère) et qui traduit le besoin exprimé dans le cahier des charges en briques logicielles. Mais il arrive (et très souvent) que le client lise les spécifications en travers et donne son aval alors qu'il n'a pas compris. Que l'analyste ne soit pas à l'aise avec les termes métiers (le jargon spécifique : un plombier n'utilise pas les même termes qu'un avionneur) du client et passe à travers certains détails importants, bref il y a rarement totale adéquation entre :

- Le CDC d'origine (qui peut être partiellement changé en cours de route)
- Les spécs (qui évoluent au cours du projet parfois)
- Le livrable (qui peut être en décalage, car le(s) développeur(s) interprète(nt) aussi des fois avec sa(leur) propre compréhension)

C'est surtout vrai sur les gros projet (plusieurs mois)
Tout ton rôle est alors de ménager tous les acteurs et de faire converger le livrable et le besoin réel des utilisateurs même si parfois ça ne respecte pas pile poil le CDC du client.

Car sinon, c'est de la logique, on est bien d'accord qu'on est responsable en cas d'écart avec le cahier des charges sur la livraison.

Chez nous on ne fait que du soft sur mesure (des moutons à cinq voir six pattes) et c'est rare qu'il y ait un CDC parfaitement précis au début. Bien souvent celui rédige le CDC ne connais que vaguement le problème (ou le process) c'est souvent un administratif loin des utilisateurs, quand ce n'est pas un consultant extérieur qui n'a jamais mis les pieds dans l'atelier par exemple... Alors les écarts on connais bien...

Cela rejoint le premier point évoqué dans la dépêche : Il faut être proche des utilisateurs finaux et les impliquer (tenir compte de leur façon de travailler, tenir compte des habitudes de l'entreprise, des termes métier, etc...) sans cependant tout prendre comme argent comptant. Certaines entreprises en ont conscience et font participer leurs salariés aux réunions préalables et demandent à ce que l'on tienne compte des remarques mais d'autres ne jugent pas que c'est nécessaire mais j'aime mieux la première façon de travailler, on est plus impliqué et c'est plus facile de sortir quelque chose de viable et d'efficace même si parfois on s'éloigne peu ou prou du CDC original. Le tout c'est d'être capable de simplifier les choses et de concilier les différents éléments pour rester dans le clous en terme de temps de développement (et de coût).

Si nécessaire le commercial peut aussi avoir un rôle important dans cette phase : rassurer le client sur un écart particulier (c'était mieux de faire comme ça plutôt que comme c'était prévu pour une raison précise), rassurer les utilisateurs, négocier des points de développement non prévus (en acceptant certains demandes, en proposant des avenants à sa proposition d'origine, etc...), bref dans les cas compliqués il reste aussi un facilitateur

[transgohan]

On est d'accord que le cahier des charges incomplet est un évènement récurrent dans notre profession.
Mais je reste sur mon idée désolé... Je ne veut pas être responsable des lacunes des autres métiers...
Être expert dans son domaine ce n'est pas savoir combler les défauts des autres domaines.
Ou alors on me propose l'augmentation qui va bien et là j'y réfléchirai.

Donc pour moi le point 1 est toujours hors contour.

[sergio_is_back]

On est d'accord que le cahier des charges incomplet est un évènement récurrent dans notre profession.
Mais je reste sur mon idée désolé... Je ne veut pas être responsable des lacunes des autres métiers...
Être expert dans son domaine ce n'est pas savoir combler les défauts des autres domaines.
Ou alors on me propose l'augmentation qui va bien et là j'y réfléchirai.

Donc pour moi le point 1 est toujours hors contour.

Tout dépend de la boite dans laquelle tu bosses... C'est pas l'esprit chez nous, tout le monde est responsabilisé à son niveau... Et les salaires sont plus que corrects... (Pour une PME j'entends)

[transgohan]

tout le monde est responsabilisé à son niveau...

J'ai un peu l'impression d'écrire noir sur fond noir, je n'ai jamais écrit l'inverse...
J'ai dit que je ne veux pas être responsable du travail des autres, c'est différent.

Bien évidemment que je suis responsable de mon propre livrable.

[defZero]

WTF ?

Que pensez-vous de cette liste ? Vous satisfait-elle sur le plan du fond ?

Belle liste avec 8 éléments.
Les énoncés sont en parfaite accord avec leurs descriptions.

Quels sont les éléments qu’on pourrait y ajouter ou qui devraient ne pas y paraître ?

Tous et aucuns à la fois.
Personne n'as la formule magique pour "mettre sur pied d’excellents logiciels", peut importe ce que ça peut bien signifier.
Sortir une liste et annoncé que ce sont les éléments qui garantiraient "d'excellents logiciels", juste .

Quelles sont les habitudes sur lesquelles vous vous appuyez au quotidien pour parvenir à concevoir d'excellents logiciels ?

Pour "concevoir d'excellents logiciels" je ne saurait dire, mais des "logiciels" qui donne satisfaction au client, là on peut discuter.

Je dirais que pour mener à bien mes projet j'ai 2 règles que je respecte scrupuleusement et qui ne mon jamais trahit :

1. Si le client ne peut exprimer ses propre besoins, alors c'est au-revoir M./Mme.
   Même si la personne est sympathique et de bonne fois, je n'est jamais vue un projet donner totale satisfaction à un client, si ce dernier était incapable d'exprimer ses besoins, ne serait ce que durant la phase d'avant projet.
   A l'inverse, j'ai vue plein de projets échoué et donc de client mécontent, parce que le livrable ne répondait pas à leur besoins (ou n'était jamais terminé, ...etc) à cause de cette "incertitude" dans les spec.
2. Si les demandes client dépasse mes capacités, ne pas hésiter à le rediriger vers un collègue.
   Que ce soit, en temps à accorder au projet ou bien en terme technique, il ne faut jamais ce surestimer.
   J'ai vu quantité de projet échouer parce-que les responsables sous-estimé le travail à accomplir ou à l'inverse surestimer leurs capacités et celle de leurs équipes.

Avec ces 2 règles, c'est déjà un bon point de départ pour entrevoir un début de projet convenable.

Vous noterez toutefois, qu'il n'existe, à ma connaissance, aucune façon de garantir quoique ce soit sur un projet logiciel.
Des personnes infiniment plus qualifiées que je ne le suis ont bien essayer de trouver des méthodes pour ça, mais rien de ferme et définitif n'as encore émergé à ce jour.
Des outils pour facilité la gestion de la durée de vie d'un projet existe bien, ainsi que des bonnes pratiques en fonction du domaine, mais encore une fois, rien de garantie.

P.S. : J'ai toujours considéré le développement logiciel plus comme un art, que comme une science exacte (coucou à toi facteur humain)

[el_slapper]

Si les demandes client dépasse mes capacités, ne pas hésiter à le rediriger vers un collègue.

ça, c'est vraiment important. J'ai vu les dégâts du syndrome du héros, 2-3 fois. J'ai moi-même commis l'erreur une fois.

pas deux.

P.S. : J'ai toujours considéré le développement logiciel plus comme un art, que comme une science exacte (coucou à toi facteur humain)

à minima de la R&D : https://www.developerdotstar.com/mag...sign_main.html - avec tous les aspects aléatoires qui en découlent.

[defZero]

J'ai vu les dégâts du syndrome du héros, 2-3 fois. J'ai moi-même commis l'erreur une fois. pas deux.
.

@el_slapper +1 (Merci pour le lien, ça semble intéressant)

C'est l'expérience qui parle, tout simplement.
En fait ce que décrit ces 8 points, peut ce résumé (en ne si limitant pas) à l' "Expérience".

[Petite apartée]
C'est aussi une des raisons pour laquelle, je suis toujours dubitatif quand je vois un Ingénieur Junior postuler à un poste de "Chef de Projet" ou de "Product Manager".

Je n'en fait pas une généralité, mais plus d'une fois j'ai vécu cette situation et à chaque fois, à la fameuse question "Pourquoi Chef de Projet ?" ils m'ont tous répondu (sans exception, mais ce n'est que mon expérience perso) que c'était parce-qu’ils avaient un diplôme d'Ingénieur (pas forcement en Info d'ailleurs) et qu'ils ne voulaient pas coder.

Pas la peine de vous dire que les projets en question n'ont jamais était mes plus agréables moments Pro.
Je code depuis bien plus de 10 ans et je ne me voit pas être Chef de Projet (en équipe de plus de 5 personnes, j’entends), tout simplement parce-que ce n'est pas le même métier.
Bien que je sois convaincu qu'il existe des Ingé Junior tout à fait apte à ce poste, je n'en est juste pas rencontré personnellement et à ce jour.
Par contre je leur concède qu'en générale, ils renvoient une bonne image aux clients.
Le gros point négatif étant que "leurs" équipes ne peuvent pas réellement compter sur eux en cas de besoin, là ou justement un "bon" Chef de Projet sera apporté des solutions.
Il ne s'agit pas toujours de solutions technique, je n'attend pas forcement d'un Chef de Projet qu'il soit un artiste du code, mais plutôt qu'il sache gérer les difficultés qui pourraient ce présenter sur son/ses projets et ça je pense requière pas mal d’expérience et de spécialisation.
Enfin, j'ai connu pas mal de Chef de Projet très compétent, mais leur point commun n'était pas le diplôme mais bien l’expérience.
[/Petite apartée]

[matthius]

Connaître un métier industriel et utiliser Rust, Julia, ou Lazarus pour réaliser cela grâce à Software Heritage et Delphi Super Page.

[GLDavid]

J'ai toujours considéré le développement logiciel plus comme un art, que comme une science exacte (coucou à toi facteur humain)

Bonjour

Content de voir quelqu'un qui se rapproche de ma vision. Je me souviens que l'on m'avait ri au nez sur ce forum il y a quelques années quand j'avais posté une telle phrase. Evidemment, la programmation, c'est des sciences exactes, je ne dis pas le contraire, mais vous devez être "inspiré par le sujet", croyez-moi, ça se ressent la motivation du programmeur sur le résultat obtenu.
Pour en revenir au sujet, je trouve que les propositions citées sont trop centrées sur le programmeur. De mon point de vue, qu'appelle t'on un 'excellent logiciel'? Et bien, c'est un logiciel qui satisfait:

1. aux utilisateurs, car il est simple d'utilisation et répond parfaitement à leurs attentes.
2. requiert un minimum de support, hors mise à jour pour ajout de fonctionnalités pourvu que cela satisfasse toujours à la 1ère condition
3. reste facile à la lecture du source code et demande des outils d'ingénierie logiciel accessibles mais évitant le déploiement d'une usine à gaz

Ouais, ça fait un peu "Small is Beautiful" mais je reste persuadé qu'un logiciel simple est garant de son succès de de son adaptation par les utilisateurs pourvu qu'il remplisse bien ses fonctions.

@++

[defZero]

@GLDavid, +1.

... Evidemment, la programmation, c'est des sciences exactes, je ne dis pas le contraire, ...

Ah, pas si évident que ça, en fait.
Si c'était totalement vrai, tout programme compilant ne pourrait jamais planter.
Ma compréhension du sujet est que la programmation est basé sur des concepts scientifiquement validé, mais qu'en pratique elle s'assimile plus à un art, tellement le nombre de variation est élevé à notre échelle (comme la peinture et la musique par exemple).
Ne pas oublier que la science s'applique à définir notre monde, alors que la programmation ce borne à coder des limites (le programme) sur un sous ensemble déjà très restreint (l'ordinateur).

Mais sinon, je comprend et suis tout à fait d'accord avec le reste.

[VBurel]

Une fois pour comprendre les problématiques, une fois pour les résoudre et une dernière fois pour satisfaire les besoins utilisateurs. C’est ce qu’on appelle dans l’industrie, le prototype, le pré-produit et le produit.

Je rappelle aussi qu'un logiciel est une sorte de roman (exécuté par une machine) et à ce titre est soumis aux droits de la propriété intellectuelle... Et la science est un moyen de se planter de manière rationnelle.

[Invité]

Cet ouvrage est bienvenu. Il vise la Qualité logicielle. Il y a une dérive techno qui fait que la technologie est devenu son propre but. En tant que "vieux de la vieille"
je suis frappé à quel point la conception est un sujet absent de nos formations d'ingénieur et à quel point le niveau de réflexion tourne autour de zéro pour ce qui concerne la qualité du logiciel en tant que produit.
Le devops, les tests unitaires, cela n'a en fait pas grand chose à voir avec la qualité, ce sont des outils qui permettent de rendre compte du travail effectué. Si un illuminé a décidé que la voiture aurait des roues carrées, les tests unitaires rendront compte du fait que les roues sont carrées.
La conception informatique, contrairement à d"autres domaines techniques n'est arrivée à aucune doctrine ni consensus. Chacun fait "ce qui lui plait" et ce qui me plait correspond à mes habitudes de faire et ma logique propre. Ce livre comble un vide effectivement.
On peut se faire la même réflexion sur l'architecture. Regardez les fiches de poste correspondant à Architecte et vous verrez que cela correspond grosso merdo à une fiche de poste de dev expérimenté. En pratique l'Architecte dans une équipe est celui qui a autorité pour imposer ses vues. Pas vraiment satisfaisant.

[koala01]

Salut,

On est d'accord que le cahier des charges incomplet est un évènement récurrent dans notre profession.
Mais je reste sur mon idée désolé... Je ne veut pas être responsable des lacunes des autres métiers...
Être expert dans son domaine ce n'est pas savoir combler les défauts des autres domaines.
Ou alors on me propose l'augmentation qui va bien et là j'y réfléchirai.

Tu sembles oublier qu'une application, c'est un mélange de quoi et de comment.

Le "quoi" correspond à un besoin auquel on veut / espère répondre car, si le programme ne répond à aucun besoin, il est inutile, et ne sera donc pas utilisé.

Cela peut commencer par une phrase lachée à un ami aussi simple que

Tiens, ce serait pas mal si on avait un programme qui ... (complète à ta guise).

Mais il faut se dire que si tu n'as pas une description correcte du quoi, tu peux faire absolument tout et n'importe quoi; et tu ne sais donc rien faire d'utile.

Or, le meilleur candidat pour décrire le besoin me semble décidément être... la personne qui est confrontée au besoin en question.

On ne peut -- bien sur -- pas te tenir pour responsable si la personne à qui l'on demande de décrire le besoin n'en a elle-même pas une vision d'ensemble, si elle "oublie" de décrire une procédure qui ne doit être appliquée que tous les dix ans, ou si elle ne comprend pas elle même correctement le besoin qui devra être rempli.

Mais n'est ce pas, en partie, ton rôle en tant qu'expert, d'orienter sa réflexion de manière à lui permettre d'exprimer correctement ce "quoi", si possible en t'assurant que tous les aspects seront décrits et qu'ils le seront correctement

Une fois que l'on a le "quoi" (ou, "suffisamment de quoi" que pour commencer à travailler, selon la méthode Agile), il est temps de se poser la question du "comment". Il se subdivise en deux aspects bien distincts: un aspect "ergonomique" (comprend : comment l'utilisateur devra utiliser l'application pour obtenir un résultat bien précis) et un aspect purement technique (dont je parlerai un peu plus loin).

L'ergonomie de l'application est essentielle et met une fois encore l'utilisateur au centre du problème, car:

• si elle ne correspond pas aux habitudes de l'utilisateur, il utilisera mal son application, et n'obtiendra pas forcément (ou du moins pas "facilement") le résultat escompté
• si une fonctionnalité de l'application est soumises à des manipulations trop complexes(*) de la part de l'utilisateur, elle risque d'être errore prone ou (trop) peu / mal utilisée.

(*) par exemple, en nécessitant une combinaison de touches difficile à obtenir, en obligeant l'utilisateur à passer par un grand nombre de fiches pour y accéder ou en l'obligeant à introduire plusieurs fois la même information.

L'un dans l'autre, seul l'utilisateur final n'est sans doute en mesure de dire si l'ergonomie correspond à "ses habitudes" et à ses besoins.

Dans le même temps, vient la partie "exclusivement technique" du comment : les structures de données et les algorithmes à mettre en place, la manière dont les informations sont sauvegardées pour "une utilisation ultérieure", la manière dont tout cela (et ce que j'aurais oublié de citer) cohabite et interagit.

Tout cela est du seul ressort du développeur / de l'équipe de développement, et le "client" ne devrait -- a mon sens --pas autorisé à y mettre son grain de sel.

... Evidemment, la programmation, c'est des sciences exactes, je ne dis pas le contraire, ...

Ah, pas si évident que ça, en fait.
Si c'était totalement vrai, tout programme compilant ne pourrait jamais planter.

C'est, justement, parce que la programmation est une science exacte qu'un programme compilant risque de planter...

Le plantage (les résultats aberrants) sont, en quelques sortes, le symptôme suprême que le développeur a "foiré quelque chose" dans sa logique ou dans sa conception. Si la programmation n'était pas une science exacte, ces "foirades" n'auraient qu'un impact très limité sur l'ensemble .