Les 6 habitudes d’un SI efficace

Manifeste pour une informatique qui sert le métier, le collectif et le temps long

Dans 80 % des cas, l’informatique n’est pas le métier de l’entreprise. C’est un moyen. Pourtant ce moyen consomme énormément, livre lentement, et finit parfois par freiner les ambitions mêmes qu’il était censé servir. Le coût financier est connu. Le coût en énergie humaine l’est moins : c’est celui qu’on dépense, à tous les étages, à compenser ce qui n’a pas été tenu.

Ce manifeste ne désigne personne. Il propose six habitudes — six pratiques à installer dans le temps, individuellement et collectivement — pour bâtir un SI qui sert. Et pour rendre au collectif l’énergie qu’on dépense aujourd’hui à colmater. Chacune engage celui qui la prend. Aucune ne fonctionne seule.

Si vous tenez ces habitudes, dites-le. Ce texte est ouvert.

Habitude 1 — Vérifier qu’on s’est compris, avant de construire

Parler ensemble n’est pas se comprendre. La traduction d’un besoin métier en langage informatique est l’acte le plus risqué d’un projet — et celui qu’on traite avec le moins de sérieux. On suppose. On enchaîne. On découvre, au mois six, qu’on a livré une Ferrari électrique pour aller faire les vendanges.

L’habitude à installer : faire de la vérification de compréhension un moment institué, court, structuré, non négociable. Ce n’est pas une réunion de plus. C’est ce qui rend toutes les autres utiles.

Ce qu’on récupère quand cette habitude est prise : deux à trois semaines par projet, des équipes qui ne portent plus la charge mentale du doute, et un métier qui cesse de découvrir au mois six que ce n’était pas ce qu’il avait demandé.

Je m’engage à vérifier que l’on s’est compris avant de construire — et à considérer cette vérification comme une partie intégrante du travail, pas comme un luxe.

Habitude 2 — Tenir un cadre clair, parce que le cadre libère

On a fini par opposer cadre et autonomie, comme si le premier détruisait la seconde. C’est l’inverse. Une équipe sans cadre clair n’est pas autonome — elle est seule. Elle dépense son énergie à arbitrer en permanence ce qui devrait être décidé une fois pour toutes. Elle vit dans la double contrainte : on me demande d’aller vite et de bien faire, sans m’aider à choisir.

L’habitude à installer : poser un cadre clair quand on manage, et respecter celui qui nous est posé — quitte à le contester par les voies prévues, jamais en le contournant. Un cadre n’est pas une prison. C’est une économie d’énergie. C’est ce qui rend l’autonomie réelle, parce qu’elle s’exerce dans un périmètre lisible.

Ce qu’on récupère : la fin du sentiment de double contrainte, des équipes qui décident sans culpabilité, et des profils qui veulent vraiment innover qui savent où aller — au lieu d’innover en cachette dans un projet qui ne s’y prêtait pas.

Je m’engage à poser un cadre clair quand je manage, et à respecter celui qui m’est posé — quitte à le contester par les voies prévues, jamais en le contournant.

Habitude 3 — Servir le besoin, pas son propre plaisir technique

Le besoin du client n’est pas toujours sexy. Il faut parfois développer en Java, sur des technos qui ne sont pas à la dernière mode, dans un cadre qui n’a rien d’excitant. Ce n’est pas une déchéance. C’est le métier.

On n’est pas, partout et tout le temps, à l’innovation. On est dans une équipe qui sert un produit métier, dans le budget, avec les outils de la maison. Et ce budget, soyons clairs : il finance, indirectement, la prime de fin d’année. Quand le budget tient, c’est aussi le pouvoir d’achat collectif qui tient.

L’habitude à installer : livrer ce qui est demandé, dans le cadre prévu, et proposer en parallèle — pas dans l’ombre — un peu de cleaning de dette technique et d’obsolescence. Une équipe qui anticipe la dette n’est pas une équipe qui se plaint. Elle protège le budget de l’année suivante.

Ce qu’on récupère : un alignement réel entre ce qu’on livre et ce qui est utile, des équipes qui ne s’épuisent pas à innover sur des projets qui n’avaient pas demandé d’innovation, et une dette qui ne dévore pas le budget d’après.

Je m’engage à servir le besoin tel qu’il est, pas tel que j’aurais aimé qu’il soit — et à proposer au cadre, non à imposer dans l’ombre, ce qui pourrait améliorer le système.

Habitude 4 — Documenter et transmettre, parce qu’on est de passage

Un jour, chacun d’entre nous quittera son poste. La fusée, elle, restera. Et si le mode d’emploi n’a pas été laissé, le successeur galérera — puis ajoutera un étage à la fusée, condamnera l’ancienne salle machine, en construira une autre, qui sera refacturée au métier.

L’habitude à installer : traiter la documentation et la transmission comme une partie du travail, pas comme un bonus optionnel. Ce n’est pas une corvée administrative — c’est un acte de confiance dans le collectif. Et un successeur bien équipé n’est pas un concurrent : c’est un allié pour la vie professionnelle. Il vous remerciera dix ans plus tard, dans un appel d’offres, dans une recommandation, dans une conversation imprévue.

Ce qu’on construit avec l’argent et au service de l’entreprise appartient à l’entreprise. La connaissance opérationnelle, les choix d’architecture, les raisons des décisions sont des biens collectifs — sauf ce qui relève de la confidentialité ou de l’IP, qui reste dans le coffre avec les bonnes accréditations.

Ce qu’on récupère : des mois de productivité à chaque rotation de poste, des projets qui ne sont plus refacturés deux ou trois fois faute de mémoire, et la possibilité de partir l’esprit léger — sans la culpabilité ou la satisfaction trouble de laisser derrière soi un système que soi seul comprenait.

Je m’engage à documenter, transmettre et rendre accessible ce que je construis — parce que je suis de passage, et que ce que je laisse parle de moi plus longtemps que ce que je dis.

Habitude 5 — Traiter l’IA comme un sujet de gouvernance, pas d’outillage

L’IT, par réflexe, a traité l’IA comme un nouveau Git. Un nouveau langage à apprendre. Un nouveau framework à maîtriser. Tout le monde devait s’y mettre — au Python, au Markdown, au Mermaid. Sauf que l’IA n’est pas un outil de plus. C’est un changement de paradigme sur la manière dont la valeur est produite, contrôlée, expliquée et auditée. C’est un déplacement de la frontière entre ce que l’humain fait et ce que la machine fait.

Plaquée sur un SI fragile, elle pose un pansement sur une jambe de bois — ou elle accélère le chaos. Adossée à un SI sain — données de qualité, systèmes sécurisés, expertises solides, gouvernance lisible — elle devient un véritable game changer. Elle libère du temps, augmente le discernement, permet de décider plus vite et mieux. Mais cela suppose qu’on ait fait le travail de fond.

L’habitude à installer : traiter l’IA comme un sujet de gouvernance avant d’en faire un sujet d’outillage. Apprendre l’outil n’est pas un problème — c’est même utile. Mais ce qui transforme une organisation, ce n’est pas l’addition de compétences individuelles. C’est la capacité collective à décider : ce qu’on demande à l’IA, sur quelles données, avec quelles garanties, sous quelle responsabilité, et au service de quelle ambition.

L’apprentissage de l’outil est un effort individuel. La transformation est un projet collectif.

Je m’engage à traiter l’IA comme un sujet de gouvernance avant d’en faire un sujet d’outillage — et à ne pas confondre le fait d’écrire un prompt avec le fait de transformer mon organisation.

Habitude 6 — Penser le SI comme un bien commun

Les habitudes précédentes ont un point commun : aucune ne tient seule. Le cadre sans la traduction est aveugle. La traduction sans la transmission est éphémère. La transmission sans l’IA bien gouvernée est dépassée. L’IA sans cadre est dangereuse.

Un SI efficace n’est pas la somme de comportements individuels vertueux. C’est un système — au sens propre. Il fonctionne quand chaque maillon tient ce qu’il doit tenir, et quand le collectif a institué les moments où l’on vérifie qu’il tient. Cela suppose deux choses, à parts égales : que chacun accepte d’être un maillon, et que ceux qui guident acceptent de guider — sans confondre l’animation et la décision.

L’habitude à installer : considérer le SI comme un bien commun de l’entreprise — et tenir sa part d’un travail qui ne fonctionne que collectivement. Travailler dans un cadre clair et partagé, ce n’est pas perdre en autonomie. C’est gagner en énergie. Celle qu’on dépense aujourd’hui à compenser ce que personne n’a tenu.

Ce qu’on récupère collectivement : du temps, de l’énergie, de la confiance, de la lisibilité, et accessoirement du budget — celui qu’on ne dépense plus en doublons, en sur-ingénierie, en projets refacturés trois fois. Du budget qui revient au métier, à l’innovation réelle, ou à la prime collective.

Je m’engage à considérer le SI comme un bien commun de l’entreprise — et à tenir ma part d’un travail qui ne fonctionne que collectivement.

Poster du Manifeste

Télécharger le manifeste (PDF)

Une invitation

Ce manifeste n’est pas un règlement. C’est un texte ouvert.

Si vous tenez ces habitudes — à votre niveau, dans votre rôle, avec vos contraintes — dites-le. Reprenez-le, partagez-le, signez-le, contestez-le si vous le voulez, mais surtout : faites-en quelque chose qui circule. Un manifeste ne vaut que par les mains qui le portent.

L’IT n’est qu’un moyen. Mais ce moyen-là engage des budgets, des carrières, des trajectoires d’entreprises et un peu de la planète. Il mérite peut-être qu’on cesse, à tous les étages, de le traiter comme une affaire individuelle.

— Laurence Poussard, architecte d’entreprise Première signataire — manifeste ouvert à co-signature

Pour signer ou réagir : laurence.poussard63@gmail.com