06-01-2017, 08:55 PM
(06-01-2017, 07:44 PM)Xenos a écrit : @Ter Rowan
Oui, mais le soucis, c'est que le banquier a un cerveau (si si!) qu'il va falloir coder. Là, je suis un peu sceptique quant à la réussite du codage, qui va générer un empilement de règles. Et niveau sécurité en général (donc triche), il suffit qu'une règle soit de travers pour que toute la pile soit vulnérable.
hum... tu cherches des modèles compliqués :
{
// répond a la tentative de trouver les offres du compte principal
nbDemandes++; if nbDemandes >15 { echo "no"; return;}
// répond à la tentative de multiplier le nombre d'avions qu'on achète
if somme(remboursements[]) < sommes(pret[]) * 0,6 {echo "no"; return;}
echo "oui";
}
le 0,6 et le 15 sont arbitraires
on est sur des assertions unitairement très simples, chacune répondant à une "faille" mais aussi peut introduire un gp plus intéressant (ex : le 0,6 se transforme en une fonction, lié à des seuils de rentabilité, etc... du coup tu veux lancer une opa en empruntant bcp tu dois d abord avoir prouvé que tu as cette capacité, par ton historique, ton ca, etc...)
ces introductions de gp peuvent être complexes mais après c est un choix gp
par contre les controles me paraissent très simples. Après évidemment il y aura des trous dans la raquete mais combien de petits malins multi arriveront a trouver cette faille ? 10 % ? et si la faille est rendue publique, bah... soit ca devient un élément de gp, soit ca permet au dev de trouver un nouveau controle