[New] Partager la gestion du risque

[ddebarbieux]

• Je ne fais pas confiance à la base de données (au back), je rajoute donc un contrôle sur les valeurs retournées par ma requête (mon appel d’API).
• Afin de me protéger face à mon client, je mets les ceintures et bretelles et je double la taille de l’infra que mon équipe m’a conseillé.

Ces deux exemples (et il y a d’autres) montrent qu’il est tentant de faire grossir un développement (anti pattern de l’éco-conception) pour se protéger des risques.

[tbroyer]

Est-ce qu'on peut généraliser ça à de la surqualité ?

J'ajouterai aussi :

• Prévoir de la haute disponibilité (base de données en cluster, failover sur l'application, disques en RAID) quand le risque d'indisponibilité est acceptable (pour des applications métiers de fonctions support dans une entreprise par exemple ; une indisponibilité de quelques heures voire quelques jours pourrait ne pas avoir d'incidence sur les recettes de l'entreprise)
• Prévoir un monitoring "poussé" voire de l'élasticité quand des dégradations de performance voire quelques erreurs (en cas de grosse affluence par exemple) serait acceptable (ça dépend bien évidemment très fortement du projet) ; ça rejoint finalement le "Getting Real" de 37 Signals (les chapitres 17 et 19 par exemple), même si leur point de vue est la réussite entrepreneuriale (un peu comme les bonnes pratiques de performance sont aussi souvent des bonnes pratiques d'écoconception)
• Prévoir une disponibilité 24h/24 7j/7 (avec organisation d'astreintes, avec monitoring et alerting, etc. systèmes qui doivent eux aussi être disponibles 24h/24 7j/7) quand les applications ne sont utilisées qu'aux "heures de bureau" en semaine (ça rejoint un peu le premier point, mais comme celui-ci était orienté durée d'indisponibilité, là on s'attache plus au moment de l'indisponibilité : la disponibilité peut être critique aux heures de bureau par exemple, mais pas du tout en soirée et/ou le weekend)
• Prévoir du stockage SSD quand des disques rotatifs (plus lents) seraient suffisants

[ACTLEM]

N'est-ce pas un peu trop générique? Même si je suis 100% en phase avec les exemples, peut-être que décliner cela en plusieurs BP sera plus opérationnel et plus proche d'une BP d'écoconception. J'ai un peu peur qu'énoncé comme cela, la BP ne soit finalement tout le temps vrai et donc ne serve à rien et surtout puisse être utilisée pour faire du greenwashing.

[devcrafting]

Juste pour être sûr sur le premier exemple : on ne parle pas de la (re)validation des données envoyées par le front au back : si le front fait des contrôles, le back est bien obligé de les refaire car c'est la responsabilité du back et non du front. Le fait que le front fasse ces contrôles est généralement dans un but UX (et parfois pour éviter des AR serveurs)

A creuser à mon avis : l'idée de surqualité comme proposé par @tbroyer, même s'il y a le risque d'être trop générique comme dit par @ACTLEM

[rlemaire]

D'accord avec @ACTLEM.

Dans les exemples, cela rejoint beaucoup la pratique "Quantifier précisément le besoin".

[ddebarbieux]

Je vais prendre un exemple concret :
Mr le maire d'une ville demande un site qui supporte 100 connections simultanées. Dans le cahier des charges, son adjoint demande 150 (au cas où). Ensuite le pilote du projet monte à 200 (ceinture/brettelle). Enfin l’équipe de dev fait un tir de performance à 400 (qui peut le plus peut le moins).

A la fin du projet, le DSI dit : « le besoin a été clairement quantifié à 100 et vous me montrez 400. »

Cet exemple abouti a une solution qui dépasse le cadre initial car chacun se protège, personne n’assume le risque.

Cette recommandation est donc différente de la #2 (Quantifier précisément le besoin).

[ACTLEM]

Je me permets de relancer cette discussion. N'est-elle pas finalement une redite de la BP 88? Si non, est-ce qu'il faut améliorer la BP 88 ou quelle serait une BP qui compléterait cette BP 88?

[ACTLEM]

Je propose 3 suggestions:

• Proposition sans suite
• Compléter la BP 88 en ajoutant la notion de "surqualité" et peut-être en parlant de l'exécution de tirs de performances qui permettent d'indiquer le minimum en terme de ressources machine
• Faire une BP sur la surqualité en reprenant les suggestions de @tbroyer, par contre quelle serait la règle de validation?

[rlemaire]

Pour moi la proposition initiale de @LGnord ainsi que les exemples de @tbroyer parlent de plusieurs sujets. Ils sont intéressants mais il n'y a pas une seule pratique qui en ressort. On y parle de programmation défensive, de taille d'infrastructure, de HD, de type de stockage, ...
On aurait peut être du lancer 4 discussions séparées.
Mais j'ai aussi l'impression que l'on rejoint des pratiques déjà existantes.
Je serais pour classer sans suite, et éventuellement s'inspirer des exemples pour créer de nouvelles règles si on a la place à la fin (par exemple « ne pas être en HD si pas besoin ».

[tbroyer]

Compléter la BP 88 ou classer sans suite.

[ACTLEM]

J'ai créé l'issue pour améliorer la BP 88 si besoin: #311