Bugs simples, de sécurité, fonctionnels, reproductibles ou pas… la liste est (très) longue. Les bugs pourrissent la vie de beaucoup de monde, même les plus pros de chez pros en souffrent. Pour preuve voici un petit florilège de ces dernières semaines, relevé au fil de l’eau. Et croyez moi, ceux qui ont développé ces sites ne sont pas des manches (facebook, google, netvibes…).







Mais alors, tout est perdu ?
Quelque soit la typologie des bugs rencontrés, il est toujours couteux et difficile de leur faire la chasse. Avoir un produit 100% fiable dés sa sortie est quasi impossible.
[Attention, ce qui suit est une caricature].
Pour garantir une haute qualité, dans le bon vieux temps, on mettait dans une pièce :
- des informaticiens (qui sont mal habillés et qui utilisent un langage connu d’eux seuls. Ils rigolent parceque les autres ne savent même pas faire une jointure en DB2),
- des fonctionnels (qui ont de beaux costumes tous neufs mais qui ne comprennent pas grand chose)
- des utilisateurs (qui connaissent leur boulot, mais qui se demandent a quoi sert la petite boite a coté de l’écran, que les autres boubourses appellent la souris. En plus ils se demandent aussi pourquoi on va encore changer de système, alors que celui qui est en place fonctionne enfin correctement).
Donc, les développeurs faisaient leur job (coder) puis des testeurs faisaient une recette complète, sur base des spécifications fonctionnelles. Long et couteux.
Désormais, et grâce aux start-up, de nouvelles méthodes ont émergées : on prend quelques types qui connaissent un peu le boulot, on saupoudre de stagiaires. Pour les occuper on leur balance quelques feuilles vite remplies de ce que certains osent appeler ’spécifications’ et hop, le tour est joué. S’il y a le moindre problème on peu taper sur le maillon le plus faible, j’ai nommé le petit gros plein de boutons qui s’habille comme un clodo : le développeur. Le commercial fait les devis, et vu qu’il pense que le php ça se fait avec photochope on est mal barré. En plus il a vendu un clone de amazon pour 10 jours de boulot. Ben oui, il suffit d’aspirer le site et de changer les images (non, ne riez pas, c’est du vécu). Les tests on s’en fiche, c’est le boulot des devs. Pas cher (quoi que, au final…), mais peu efficace.
Puis est venu le web 2.0. Donc, pour éviter de dépenser trop d’argent, on va demander aux internautes de faire les tests, d’où cette flopée de versions bêtas qui fleurissent partout. Cela permet de sortir nombres bugs, mais également de faire des tests de montée en charge, de benchmarker un peu tout et n’importe quoi… et surtout c’est quasi gratuit. En cas de pépin, vu que le dev a un blog et qu’il est sympa pour un geek, personne ne va lui gueuler dessus. En plus les internautes sont content d’avoir eu des invitations, ils ont l’impression d’être important. Du coup ils vont faire un max de pub. Trop cool.
[Fin de la caricature]

Ami lecteur, tu l’aura compris, l’informatique c’est un peu tout et n’importe quoi finalement. C’est toute une typologie qui se cache sous le terme bug : spécifications insuffisamment détaillées, cas non prévus, erreurs dans le code, problèmes de montée en charge, patch système qui change le format de date, problème réseau…
Il est bien entendu possible de mettre en place des méthodes finalement simples pour éviter les problèmes : de bonnes specs (avec par exemples des use cases), du code clair et lisible, une architecture intelligente, des tests… Tout cela demande un peu de connaissances, de temps, de compréhension et d’outils.
Un bon bug tracker remplacera avec bonheur les mails du type ‘ca marche pas, bor@#l‘. Bugzilla ou Mantis par exemple.
Liens externes
Voici un tout petit échantillon de ce que j’ai pu trouver ces derniers jours concernant le sujet. Comme vous pouvez le constater, tout le monde est concerné :
Electronique Arts, centre de test des jeux a venir sur le marché.
Une employée en colère efface toutes les données de son entreprise
L’Iphone attaqué par un enfant de 11 ans
Failles de sécurité MySpace et Facebook
Histoires de hackers
google freaking out
Après le bug de l’an 2000, le bug de l’an 2038


















Le web a engendré des nouvelles méthodes de développement, dont les méthodes agiles, qui permettent d’être beaucoup plus réactives et souples, ce qui est justifié dans la période actuelle ou l’innovation et la concurrence sont très exacerbés. Il est vrai que les vieilles méthodes (cahier des charges, cahiers de conception, développement, recette) semblent totalement dépassées par les mouvements actuels.
yes, et aussi l’extreme programming.
question methode, il en existe vraiment pas mal (structuree, objet, imperative…)
Quelle que soit la méthode, on sera toujours dans la trinité du "coût-qualité-délai". Et c’est l’homme et son organisation qui sont à la base de tout ça : construction, maintenance, archivage, etc. C’est le cycle de la vie, ainsi va le monde. C’est aussi le principe d’entropie appliqué au logiciel. Tout n’est donc pas certainement perdu.
C’est l’inverse qui me ferait peur : peut-on imaginer un système sans bug ? Une sorte de mouvement perpétuel, une horloge parfaite qui n’a plus besoin de l’homme. Brrr… Ca me fait froid dans le dos !
Le cahier des charges a au moins un intérêt commercial : celui de définir aussi précisément que possible ce qui sera fait.
Ce qui n’est pas rien.
Un hacking d’un nouveau genre :
http://www.textually.org/textual...
pas de probleme ;)
ceci dit j’ai vu une video il y a peu ou un boutonneux modifiait le texte d’un panneau de signalisation d’autoroute via son GSM.