Chaque développeur a l’occasion dans sa vie de voir de vrais désastres sur le plan technique. Voici ceux que j’ai vus, en sachant que de votre côté n’hésitez pas à raconter les vôtres dans les commentaires !
Débloque les + belles offres tech en 10 mins
De nombreux sites web contiennent une page d’authentification, cependant très peu sont réellement sécurisés. En effet de trop nombreuses personnes considèrent que si une fonctionnalité n’est pas disponible dans l’IHM alors personne n’ira l’utiliser. Sauf que… rien n’est plus faux ! Une fonctionnalité, même cachée, reste accessible dès lors qu’aucun contrôle est fait pour s’assurer du contraire, et ces contrôles doivent être impérativement faits côté serveur.
Alors on va le redire encore une fois, mais tout traitement de validation d’une requête doit être intégralement effectué côté serveur. Ce qui est fait côté client permet juste de soulager le serveur afin d’éviter que le client n’envoie des demandes vraiment incorrectes dans les cas d’utilisation nominaux, mais il ne faut en aucun cas présumer que l’utilisateur passe vraiment par le client « officiel » de votre application pour envoyer ses requêtes.
On parle plus longuement de la sécurisation des applications web ici, aussi je ne vais pas m’épandre sur le sujet. Mais si vous ne respectez pas ces règles de base votre application ressemblera à ceci :
Dans une vie antérieure j’ai eu l’occasion de travailler sur une application de partage de données en ligne. Ils vantaient la haute sécurité de leur plateforme grâce à un triple cryptage des données (sic ! on remarquera au passage la confusion entre cryptage et chiffrage…) ainsi que des mécanismes d’authentification forte grâce à un boîtier. Sauf que derrière n’importe quel utilisateur pouvait accéder à n’importe quelle fonctionnalité en sniffant les requêtes qui passaient avec Firebug et un peu de jugeote. Et de la même manière on pouvait parfaitement lire les données sous « triple cryptage » car la clef n’était pas fonction du compte utilisateur, mais bien du mot de passe utilisateur au moment de l’enregistrement des données ! Et donc c’est cette clef qui était utilisée pour les déchiffrer, quelque soit l’utilisateur qui requêtait la ressources… Superbe la sécurité ! Et bien évidemment n’importe qui pouvait accéder aux fonctionnalités d’administration. 😉
Dans le même genre, une autre application sur laquelle j’ai travaillé ne contrôlait absolument pas les accès aux ressources, ni aux fonctionnalités d’ailleurs. Le discours du chef de projet était que si l’utilisateur ne voit pas la fonctionnalité il ne l’utilisera pas. Et c’est comme ça qu’avec un petit Javascript on pouvait intégralement vider la base de données.
Ces deux applications, qui existent encore, manipulent des données personnelles et sont soumises à la CNIL. Vous me demanderez donc pourquoi je n’ai pas travaillé à les sécuriser… La réponse est simple : le management estimait que ce n’était pas prioritaire, tant qu’aucun utilisateur ne s’en apercevait !. Eh oui, nombre de désastres techniques et technologiques sont dûs au management bien plus qu’aux développeurs, et pourtant ce sont ces derniers qu’on blâme systématiquement… Le privilège du chef qu’on vous dit !
Toujours dans cette même banque, des applicatifs internes avaient été développés autour d’un progiciel d’un éditeur externe. Ceux-ci manipulaient des quantités de données financières. Il y avait des batchs qui tournaient toutes les nuits et faisaient de nombreux calculs, lesquels faisaient appel à des multiplications et divisions. Or ces dernières étaient faites sur des nombres de type float et double. Il se trouve que le fonctionnement des ordinateurs fait que ceux-ci ne sont pas exacts, et ça devient très impactant sur les grands nombres. C’est ainsi par exemple qu’on pourrait avoir :
9999999999999999.0 = 10000000000000000.0
C’est la raison pour laquelle ces nombres ne doivent jamais être inclus dans des opérations mathématiques sur de grands nombres, en particulier pour les multiplications. À partir du moment où les valeurs s’approchent du million les problèmes de précision commencent à se faire sentir, alors imaginez ce que ça peut donner quand on passe quotidiennement des millions de transactions avec de tels logiciels… Les banques sont bien conscientes de ce problème, même si elles s’en cachent. J’ai entendu parler dans le milieu de mécanismes visant à rééquilibrer ces erreurs de calcul entre établissements, je ne sais pas ce qu’il en est pour de vrai.
Le système ORM Hibernate pour Java utilise un système de caches pour optimiser les traitements, ce qui explique pourquoi il faut user de la plus grande prudence si vous mélangez du SQL natif et de l’Hibernate. En particulier pour les mises à jour de base de données il convient de ne jamais écrire de SQL natif mais plutôt de passer par du HQL pour éviter les mauvaises surprise.
Bref j’ai eu le malheur de travailler sur une application qui ne respectait pas ce principe, et comme on pouvait s’y attendre elle réussissait à corrompre ses propres données en cours de route, bloquant certains clients ! Par conséquent il y avait de nombreux appels des utilisateurs, excédés d’être bloqués en permanence par cet applicatif si pourri. Et un développeur devait régulièrement interrompre son travail pour aller directement éditer la base de données de production…
Les utilisateurs étaient si satisfaits de l’application que certains ont fait intervenir un huissier pour qu’il constate les erreurs dûs à l’application et obtiennent réparation !
Alors bien évidemment les développeurs ont réclamé du temps pour pouvoir corriger les problèmes, très nombreux, mais la direction leur a opposé qu’il n’y avait pas le budget pour corriger les bugs, juste pour de nouvelles fonctionnalités ! Par contre en cas de pépin elle n’hésitait pas à blâmer les développeurs.
On se demande pourquoi dans de telles organisations le turn-over est si élevé…
Certains désastres techniques sont dûs à des développeurs maladroits, on ne peut le nier. Cependant à force de mettre la pression sur les gens pour développer des fonctionnalités pour hier et ne pas écouter leur base, il est clair que les directions d’entreprise ont une très large responsabilité dans ces catastrophes. Et ce d’autant plus si elles cherchent à payer leurs dévs le moins possible…
Besoin de tester ton niveau en développement informatique ?
Cet article vous a plu ? Vous aimerez sûrement aussi :
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
Changer d’entreprise, c’est excitant. Nouveau challenge, nouveaux collègues, nouveau café. Mais, bien souvent, on oublie…
Ça n’étonnera personne si nous affirmons que le monde du développement logiciel est en constante…
En Allemagne, le travail en tandem à temps partiel, aussi appelé « jobsharing » est…
On se retrouve comme d'habitude pour le début du classement qcm saison automne ! Mais…
La saison printemps des tests techniques WeLoveDevs s'est terminée le 31 mai, et c'est Axel…
