Comment rater son projet informatique en 8 étapes simples
Vous voulez être sûr que votre projet informatique soit un fiasco retentissant ? Vous rêvez de le voir se transformer en désastre épique ? Vous êtes au bon endroit. Voici une méthode détaillée pour saboter vos ambitions numériques en toute efficacité et garantir à votre organisation dépassements de budget, retards interminables et solutions inadaptées :
1. Ne définissez pas clairement vos objectifs
2. Ignorez la communication avec les parties prenantes
3. Ne précisez pas les responsabilités
4. Sous-estimez les ressources nécessaires
5. Changez constamment les priorités
6. Zappez la phase de tests
7. Évitez toute documentation
8. Oubliez l’accompagnement des utilisateurs
Photo de Heidi Kaden sur Unsplash
1. Ne définissez pas clairement vos objectifs
La base pour échouer, c’est de se lancer sans avoir la moindre idée de ce que vous voulez accomplir. Pourquoi perdre du temps à analyser vos besoins ou à clarifier vos priorités ? Qui a besoin d’objectifs clairs ? C’est pour les faibles… Lancez-vous sans prendre le temps d’identifier vos besoins ou de fixer des priorités. Vous verrez bien où cela vous mène.
Oubliez surtout cette notion de SMART (Spécifique, Mesurable, Atteignable, Réaliste, Temporel). C’est bien trop réducteur. Privilégiez un objectif vague du genre "Améliorer la productivité" ou "Accélérer la transformation digitale". L’avantage corollaire, à part celui de vous faire gagner du temps au démarrage, c’est qu’il sera difficile de vous reprocher d’avoir raté les objectifs, puisqu’ils sont assez flous pour que vous puissiez argumenter le contraire.
Autre possibilité : vendez des objectifs inaccessibles. Pourquoi ne pas viser les étoiles tout de suite ? "Devenir leader du marché de l’IA d’ici la fin de l’année" : ça, c’est un objectif qui claque. Que cela soit réalisable ou non, peu importe. L’essentiel, c’est de vendre du rêve.
Astuce Bonus – Si vous avez malgré tout dû définir des objectifs, modifiez-les en cours de route. Changez régulièrement de cap pour désorienter tout le monde.
Pourquoi c’est une recette inratable pour échouer
Un projet sans objectifs clairs devient rapidement un casse-tête. Sans vision, impossible de savoir si vous avancez dans la bonne direction. Résultat : confusion générale, décisions contradictoires, et frustration à tous les niveaux.
Photo de Phil Hearing sur Unsplash
2. Ignorez la communication avec les parties prenantes
Impliquer vos collaborateurs, vos utilisateurs ou même votre direction ? Parler à vos collègues, vos utilisateurs ou vos décideurs ? Quelle perte de temps. Vous êtes le responsable de projet, vous savez mieux qu’eux ce qu’ils veulent. Inutile donc de consulter ces fameux "utilisateurs finaux" ou de chercher à comprendre leurs besoins. Après tout, pourquoi prendre le risque qu’ils pointent du doigt des incohérences ou des besoins oubliés ?
Avancez seul, sans consulter personne. Vous éviterez ainsi ces interminables réunions où des idées utiles pourraient émerger. Tous ces adages : “Seul, on va plus vite. Ensemble, on va plus loin” ; “Seul on peut briller, mais ensemble, on éclaire le monde" ; "Une main seule ne peut applaudir” ; "Aucun de nous n’est aussi intelligent que nous tous ensemble" ? Des fadaises de consultant…
Si les parties prenantes tiennent vraiment à savoir ce qui se passe, elles n’ont qu’à deviner. Vous pouvez même organiser un petit jeu : "À quoi ressemble le projet aujourd’hui ?" Bonus si personne ne donne la même réponse. Un peu de mystère, c’est toujours sympa. Et quoi de plus délicieux pour eux que le frisson de la surprise qu’ils pourraient éprouver au dernier moment en découvrant que le projet ne correspond pas/plus du tout à leurs besoins ou à leurs priorités stratégiques.
Un sponsor ou un utilisateur insiste et s’obstine à poser des questions ? Répondez vaguement, idéalement avec des phrases creuses du type "C’est en cours de traitement" ou "Nous avons une vision à long terme, vous comprendrez bientôt". Avec un peu de chance, il abandonnera. La meilleure communication, c’est celle qui n’a pas besoin d’exister.
Astuce Bonus – Oubliez partiellement ou totalement les réunions de suivi. Qui a envie de s’enchaîner à un calendrier régulier avec des bilans clairs et des responsabilités définies ? Si un calendrier de COPIL est quand même fixé, placez les réunions à des moments qui arrangent le moins de monde possible. Annulez les points au dernier moment. Si par hasard un point a quand même eu lieu, pas de compte-rendu. Les absents n’avaient qu’à être là et les présents n’avaient qu’à prendre des notes.
Astuce Bonus supplémentaire – Ignorez aussi les retours d’expérience de projets similaires. Votre projet est unique, les expériences des autres ne peuvent pas être applicables dans votre cas.
Pourquoi c’est une recette inratable pour échouer
Un projet sans collaboration ni retour d’information crée un fossé entre les attentes et la réalité. Les solutions livrées ne répondent pas aux besoins, et les utilisateurs les rejettent en bloc. Pire encore, vous perdez leur confiance, rendant tout ajustement futur beaucoup plus compliqué.
3. Ne précisez pas les responsabilités
Pourquoi se donner la peine de clarifier les responsabilités au sein de votre projet ? Le RACI (Responsible, Accountable, Consulted, Informed), cet outil ennuyeux qui définit et formalise qui est responsable de quoi, qui doit être tenu informé et qui doit simplement donner son avis, c’est totalement superflu. Après tout, chacun sait parfaitement ce qu’il a à faire, n’est-ce pas ? Pas besoin de perdre du temps à écrire des évidences. De toute manière, ce genre de formalisation, c’est pour les détails, et les détails, ce n’est jamais vraiment crucial, surtout dans un projet à grande échelle.
Mieux vaut adopter une approche "au feeling". En réalité, si on ne sait pas vraiment où commencent et finissent ses responsabilités, c’est plutôt une opportunité. Il y a fort à parier que comme ça, dans le doute, chacun s’attachera à traiter plus que son périmètre. Tout sera donc parfaitement couvert, plutôt deux fois qu’une, et dans les temps.
De plus, ça encourage l’autonomie et l’esprit créatif. Bonne occasion de voir de quoi chacun est capable.
Astuce Bonus – Si malgré tout un RACI a été défini, ne pas oublier de ne pas l’actualiser au fur et à mesure de l’avancement du projet. Il ne manquerait plus qu’il soit à jour et fiable.
Astuce Bonus supplémentaire – Créez des réunions sans ordre du jour. Imparable pour que ces réunions n’aboutissent à rien.
Pourquoi c’est une recette inratable pour échouer
Sans un RACI, personne ne sait qui fait quoi, ni qui a l’autorité de décider. Vous serez tous pris dans un tourbillon de discussions sans fin, où chaque tâche sera abandonnée à la bonne volonté de l’un ou de l’autre. Résultat : une multitude de responsabilités qui se croisent, s’emmêlent et finissent par laisser tout le monde dans l’incertitude. Le chaos est garanti, et le projet finira par être abandonné, sans que la moindre responsabilité puisse être attribuée. Mais ça peut en arranger certains…
Photo de Rob Curran sur Unsplash
4. Sous-estimez les ressources nécessaires
Vous voulez pimenter un peu plus votre projet ? Faites tout avec une équipe réduite, un budget minimal et des outils obsolètes. Parce qu’après tout, qui a vraiment besoin de temps, d’argent, ou de personnes compétentes pour mener à bien un projet informatique ? C’est tellement surfait. Si quelqu’un émet des doutes, accusez-le d’être pessimiste.
Commencez par minimiser les délais. Trois mois pour intégrer un ERP mondial ? Trop long. Visez trois semaines, c’est bien plus ambitieux. Les développeurs adorent les deadlines intenables, ça leur donne un sens du défi (et des cernes XXL). En revanche, ne lésinez pas sur le café et autres boissons énergisantes.
Côté budget, soyez créatif : divisez les estimations initiales par deux, voire par trois. Pourquoi investir correctement alors que vous pourriez économiser maintenant et payer le prix fort plus tard en réparant les dégâts (de toute façon éventuels, toujours ces sacrés pessimistes) ? Avec un peu de chance, tout rentrera dans le budget. Des imprévus surgissent toujours, qu’il faudra prendre en compte ? N’importe quoi.
L’équipe ensuite. Prenez deux stagiaires et confiez-leur la gestion d’une transformation numérique complète : après tout, ils savent coder un site web, ça ne doit pas être si différent. Les experts, c’est pour les mauviettes.
Cerise sur le gâteau : supprimez les ressources de back-up. Les gens n’ont qu’à ne pas tomber malades ou partir en vacances, non ? Vous créez ainsi une ambiance de travail palpitante où chaque absence devient une crise, et où tout le monde se sent constamment indispensable. Bref, une vraie équipe soudée par le stress.
Astuce Bonus – Confiez le projet à une équipe sans compétences spécifiques. Avec un peu de chance, ils apprendront sur le tas... ou pas.
Astuce Bonus supplémentaire – Insistez sur des outils ou technologies dépassés ou sur le point d’être dépassés. Voilà des solutions éprouvées ! Tous les bugs ont de fortes chances d’avoir déjà été résolus. Bon, OK, pas d’évolutions à venir et des difficultés à trouver les ressources pour assurer la maintenance. Mais on peut se débrouiller. Prenez l’exemple du COBOL, encore largement présent dans de nombreux applicatifs bancaires : il suffit de faire appel à des développeurs partis à la retraite. Un problème, une solution. Ou bien est-ce “Une solution, un problème” ?
Pourquoi c’est une recette inratable pour échouer
Un manque de ressources conduit à des délais interminables, des coûts qui explosent, et une équipe épuisée. Sans compétences adéquates, vous êtes sûr d’obtenir une solution mal conçue, voire inutilisable.
5. Changez constamment les priorités
Rappelez-vous : un projet informatique a besoin de stabilité pour avancer. Pour garantir l’échec, le projet doit absolument être en permanence sur un terrain mouvant où rien n’est jamais vraiment décidé ni finalisé. Pour le faire échouer, chamboulez les priorités à chaque réunion. Ajoutez de nouvelles fonctionnalités en cours de route, supprimez celles déjà en développement, et soyez flou sur les délais. Une semaine, vous vous concentrez sur l’optimisation de l'interface utilisateur, et la semaine suivante, hop ! On se lance sur une refonte totale du backend, pour une raison floue. Attachez-vous à ne jamais rien finaliser avant de passer à autre chose. Cela assurera des délais infinis et un résultat incohérent.
Grâce à ces changements de cap continus, personne ne sait vraiment où l’on va. Mais le plus important, c’est que tout le monde galope dans la même direction.
Astuce Bonus – Justifiez tout cela en invoquant l’agilité, même si vous n’en maîtrisez pas les principes. L’agilité, c’est un peu comme un joker dans un jeu de société : vous pouvez l’utiliser à tout moment, même si vous n’avez aucune idée de ce qu’il représente réellement. Alors pourquoi ne pas invoquer ce terme pour justifier chaque changement de priorité ou chaque rebondissement dans le projet ? Une simple mention d’agilité dans la conversation suffira à donner une impression de maîtrise totale et à faire taire les détracteurs.
Attention ! Ne vous souciez pas de comprendre les principes fondamentaux de l’agilité, comme la collaboration continue ou la livraison incrémentale de valeur. Ce sont des détails ennuyeux ! En revanche, vous pouvez toujours citer des mots-clés comme "Sprint", "BurnDown Chart", “Epic”, tout en changeant les priorités tous les deux jours. Cela va instantanément renforcer l’impression que vous êtes à la pointe de l’innovation et de la gestion de projet moderne.
Pourquoi c’est une recette inratable pour échouer
Le "scope creep" (dérive des objectifs) épuise les équipes et allonge les délais. Chaque changement entraîne des coûts supplémentaires et crée des incohérences dans la solution finale.
6. Zappez la phase de tests
Le développement est fini ? Mettez directement votre solution en production. Les tests, quelle perte de temps, n'est-ce pas ? De plus, les tests, c’est pour les froussards. Si des bugs apparaissent, ce n’est pas grave : vos utilisateurs auront le plaisir de les découvrir en direct, ce qui offre une occasion d’enfin discuter avec eux. D’ailleurs, pourquoi s’embêter à tester avec quelques personnes en interne quand vous pouvez avoir l’avis de centaines d'utilisateurs en même temps, en direct ? À ce moment-là, vous pourrez vraiment observer les problèmes en temps réel, ce qui est bien plus efficace. D’ailleurs, plus il y a de monde qui détecte des erreurs, plus cela prouve que votre outil est utilisé ! C’était le but, non ?
De plus, la résolutions d’erreurs et de bugs sont une excellente occasion de souder l’équipe. Et, franchement, quoi de plus gratifiant que d’être pris au dépourvu par un bug majeur lors de la mise en production ? Cela crée un excellent moment de tension et de panique, bien plus dynamique qu’un test préventif (cf. Conseil n° 4).
De plus, quelques problèmes en production permettent à toute l’organisation de se rappeler que la DSI existe et qu’elle est indispensable.
Astuce Bonus – Lancez-vous un vendredi soir, sans plan de secours. Avec un peu de chance, vos équipes passeront le week-end à réparer les dégâts. Autre option, choisissez des moments clés comme ;
les vacances d'été, de fin d'année ou les congés scolaires, c’est à dire quand les effectifs sont souvent réduits ;
la fin d’année (novembre à janvier), mais uniquement si votre organisation connaît à ce moment-là un pic d'activité ; ou encore la période des soldes…
les périodes de clôtures trimestrielles, semestrielles ou annuelles qui impliquent une forte activité pour les services financiers et administratifs. Une interruption ou un dysfonctionnement pourrait entraîner des erreurs critiques dans les rapports financiers ou le traitement des données. Quel plus beau ratage ?
le lancement de produits majeurs par votre entreprise : une impossibilité de passer des commandes constitue également un beau KPI d’échec ;
les événements réglementaires importants (une certification, des audits…) ;
une mise à jour majeure d’autres systèmes : un déploiement simultané pourrait entraîner des incompatibilités ou compliquer la résolution des problèmes ;
les périodes de surcharge des équipes IT, déjà engagées sur d'autres projets critiques ou dans la résolution de crises ;
Vendredi 13 ou la pleine lune, avec un peu de chance, certains des collègues sont superstitieux.
Pourquoi c’est une recette inratable pour échouer
En négligeant les tests, vous garantissez des pannes répétées, une expérience utilisateur désastreuse, et une perte de confiance généralisée.
Image générée par DALL-E 3
7. Évitez toute documentation
Pourquoi rédiger des documents de suivi, des guides ou des manuels ? C’est chronophage et franchement ennuyeux. Qu'est-ce que ça peut bien apporter au projet ? La documentation, c’est pour les amateurs de paperasse. Que vous soyez en train de définir des spécifications, de noter des décisions prises en réunion ou même de rédiger des comptes-rendus, n'y pensez même pas. C’est une activité absurde qui vous éloigne de l’action ! De toute façon, personne ne lit la documentation.
Astuce Bonus – Ne tenez surtout pas un registre des décisions prises (comme déjà évoqué dans l’Astuce Bonus du Conseil n°2) ! Oubliez de noter les choix stratégiques, les échanges clés ou les ajustements importants, et laissez les choses se régler au fur et à mesure. N'ayez aucune trace écrite de ce qui a été dit ou décidé. Les malentendus et la confusion seront des moteurs d’inefficacité inégalés !
Astuce Bonus supplémentaire – Si vous rédigez quelque chose, assurez-vous que ce soit incompréhensible. Utilisez des termes abscons, beaucoup d’acronymes (sans les définir). Ne notez pas les numéros de version, la date de mise à jour, l’auteur. Attachez-vous particulièrement à rendre les documents de formation et de support indigestes et le plus long possible ; ou alors le plus court possible, avec le moins de détails utiles. Surtout, jamais d’illustration, que du texte ! Échec d’adoption de la solution et de sa maintenance garanti.
Pourquoi c’est une recette inratable pour échouer
Sans documentation, tout devient opaque. La maintenance est un cauchemar, les nouveaux venus mettent des semaines à comprendre le fonctionnement, et les utilisateurs finaux perdent un temps précieux à essayer de deviner comment utiliser la solution.
Photo de Mediamodifier sur Unsplash
8. Oubliez l’accompagnement des utilisateurs
Contre toute attente et malgré vos efforts, le projet est livré. Considérez que votre travail est terminé. Laissez les utilisateurs se débrouiller. Après tout, votre rôle était de livrer la solution, pas de vous assurer qu’elle soit utilisée correctement. Pourquoi perdre du temps à expliquer aux utilisateurs comment utiliser le système ou à les former pour maximiser l’efficacité de l’outil ? Ils sont censés être des experts, non ? De toute façon, c’est connu, on s’approprie une solution d’autant mieux qu’on bataille pour l’utiliser. Mieux vaut que les utilisateurs fassent eux-mêmes leurs erreurs et se débrouillent avec des interfaces obscures et des fonctionnalités mystérieuses. Le but est de renforcer leur capacité à tout découvrir par eux-mêmes, un peu comme une chasse au trésor numérique… mais sans carte.
Rappelez-vous, l’expérience utilisateur n’a aucune importance. Tant que le logiciel fonctionne quelque part derrière l'écran, tout est parfait. Les utilisateurs peuvent se débrouiller, ils n’ont qu’à chercher dans les menus déroulants, appuyer sur tous les boutons, et au bout d’un moment, ils trouveront ce qu’ils cherchent. Si ce n’est pas le cas, eh bien, il suffit de laisser le temps faire son œuvre : ils finiront par s’habituer à l’interface labyrinthique et aux options non intuitives. D’ailleurs, quand on leur proposera dans quelques années une solution plus ergonomique, on sait très bien qu’ils rechigneront à abandonner la solution qu’ils ont eu tellement de mal à adopter.
Astuce Bonus – Ignorez les demandes de formation ou d’assistance ou justifiez l’absence d’accompagnement par "l’autonomie et l’innovation". Argumentez qu’il ne s’agit pas d’un manque d’accompagnement, mais d’une stratégie subtile pour encourager l’innovation personnelle. Chaque utilisateur qui trouve par lui-même comment utiliser l’outil devient, en quelque sorte, un pionnier de l'ère numérique. Et soyons honnêtes, un problème résolu par un utilisateur est bien plus satisfaisant que si on lui expliquait comment le résoudre en amont. Il faut voir cela comme une sorte de rite de passage vers la maîtrise totale du système. En gros, ce manque de formation ? C’est de l’autonomie accélérée. Plus c’est difficile, plus ils apprennent vite !
Astuce Bonus supplémentaire – Si vous ne pouvez pas éviter l’organisation d’une formation, organisez une session rapide où personne n’a le temps de poser de questions. Surtout ! pas de support de formation, on ne le répétera jamais assez.
Pourquoi c’est une recette inratable pour échouer
Sans un minimum de formation, les utilisateurs sont perdus et frustrés. Cela entraîne des erreurs coûteuses, des interruptions de travail et une mauvaise adoption de l'outil. Si personne ne sait comment utiliser correctement le système, l’outil est inutile, peu importe sa sophistication. En fin de compte, vous aurez une équipe démoralisée, un retour sur investissement nul, et un échec assuré.
Photo de Joshua Sortino sur Unsplash
En Conclusion
En suivant ces conseils, impossible de rater votre projet informatique. Il suffit en somme d’être négligent, désorganisé et sourd aux besoins des autres. Ces conseils sont ridicules, il est évident qu’il faut faire le contraire ? Je suis sûre que vous avez (au moins) une fois dans votre carrière rencontré de telles situations. N’hésitez pas à les partager en commentaire !
