Hconsul est née d'un constat simple, formé au fil de {{ANNEES_EXPERIENCE}} années passées sur des systèmes d'entreprise complexes : la plupart des projets informatiques n'échouent pas par manque de compétence technique, mais parce que personne n'a pris le temps de comprendre le problème avant de proposer une solution.
Nous avons construit cette société pour travailler autrement.
Le fondateur de Hconsul a passé {{ANNEES_EXPERIENCE}} années à concevoir et faire évoluer des systèmes d'entreprise — {{CONTEXTES_TECHNIQUES}}. Assez longtemps pour voir se répéter les mêmes situations, dans des organisations pourtant très différentes.
Aucune de ces situations ne résultait d'une incompétence. Elles résultaient d'une distance : entre celui qui vend et celui qui construit, entre celui qui décide et celui qui subira la décision, entre ce qui est écrit dans un contrat et ce qui se passe réellement en production.
Hconsul a été créée pour supprimer ces intermédiaires. L’ingénieur qui analyse votre problème est celui qui construira la solution. Il n’y a pas de commercial qui promet, puis de chef de projet qui traduit, puis de développeur qui découvre. Il y a une seule personne responsable du début à la fin — et donc une seule personne à qui demander des comptes.
Cela impose une limite que nous assumons : nous ne pouvons pas absorber n’importe quel volume. Nous préférons décliner une mission plutôt que de la confier à quelqu’un qui n’y comprendrait rien.
Nous ne sommes pas une grande société de conseil et nous n’essayons pas d’en avoir l’apparence. Nous n’avons pas de références clients à afficher, pas de chiffres d’activité, pas de logos sur une page d’accueil. Sur certains besoins — un programme à cinquante personnes, un déploiement international — une structure établie sera mieux placée, et nous vous le dirons.
Ce que nous apportons est différent : une expertise technique réellement senior, une décision qui se prend dans l’échange plutôt qu’en trois semaines, et des engagements écrits qui vous protègent mieux qu’une réputation.
La compétence technique se vérifie en quelques heures. La façon dont quelqu’un se comporte quand le projet dérape, cela prend des mois. Nous préférons l’écrire dans le contrat dès le premier jour.
Trois verbes, dans cet ordre, parce que chacun conditionne le suivant.
La qualité d’un système se joue avant la première ligne de code. Comprendre le métier, identifier les vraies contraintes, choisir une structure adaptée à la complexité réelle : c’est le travail le moins visible et celui qui détermine tout le reste.
Un système qui fonctionne en démonstration et s’effondre en production n’a rien accompli. Nous écrivons du code destiné à être lu, repris et modifié par d’autres, testé là où le risque le justifie, et livré par petits incréments pour que les écarts se voient tôt.
Un logiciel n’est jamais terminé. Ce qui distingue un système qu’on améliore pendant dix ans d’un système qu’on jette au bout de trois, ce n’est pas sa technologie : c’est la facilité avec laquelle on peut le changer sans le casser.
C’est le seul critère qui compte réellement. Pas l’élégance de l’architecture, pas la modernité de la pile technique. La question est de savoir si le système tient quand la charge monte, si l’équipe ose le modifier un vendredi, et s’il sera encore maintenable quand nous serons partis.
Nous ne visons pas la taille. Nous visons une position précise : celle du prestataire qu’on rappelle deux ans plus tard pour le sujet suivant, parce que le précédent s’est bien passé et que le système livré tient toujours.
Construire nos premières références sur des projets où notre niveau d’exigence fait une différence mesurable, et les documenter honnêtement, y compris ce qui n’a pas fonctionné.
Réunir un réseau restreint d’ingénieurs seniors partageant la même exigence. Nous préférons refuser une mission plutôt que d’y placer quelqu’un qui ne serait pas au niveau. Cette contrainte limite notre croissance ; nous l’assumons.
Contribuer à ce qui manque dans notre métier : de la transmission. Publier ce que nous apprenons, partager nos retours d’expérience, y compris les décisions techniques que nous regrettons. Le conseil informatique souffre d’un déficit de sincérité ; nous préférons prendre le contre-pied.
Toute société affiche des valeurs. Elles ne signifient quelque chose que si elles interdisent quelque chose. Pour chacune, nous précisons ce qu’elle nous coûte.
Ce que ça veut dire
Du code écrit pour être lu par quelqu’un d’autre. Des tests là où le risque le justifie. Des décisions d’architecture documentées avec leurs raisons, pour qu’on puisse les comprendre dans deux ans.
Ce que ça nous interdit
Livrer quelque chose qui fonctionne mais que nous ne serions pas prêts à maintenir nous-mêmes. Accepter un délai qui n’est tenable qu’en sacrifiant la qualité — nous proposons alors de réduire le périmètre, pas la rigueur.
Ce que ça veut dire
Ce qui est annoncé est livré. Quand une difficulté apparaît, elle est signalée le jour où nous la découvrons, pas à la revue de fin de mois.
Ce que ça nous interdit
Absorber un problème en silence en espérant le rattraper. Une mauvaise nouvelle annoncée tôt reste gérable ; annoncée tard, elle devient une crise.
Ce que ça veut dire
Nous testons, nous lisons, nous nous trompons sur nos projets internes plutôt que sur les vôtres. Une technologie ne nous intéresse que lorsque nous comprenons quel problème elle résout et lequel elle crée.
Ce que ça nous interdit
Introduire une technologie dans votre système parce qu’elle nous intéresse. L’innovation qui se paie en dette de maintenance n’est pas de l’innovation, c’est un transfert de risque vers vous.
Ce que ça veut dire
Un avis technique argumenté, y compris quand il contredit la demande. Nous vous dirons si votre projet ne nécessite pas les moyens que vous envisagez, ou si un autre prestataire est mieux placé.
Ce que ça nous interdit
Vendre une prestation dont nous doutons de l’utilité. Facturer une complexité que nous avons nous-mêmes introduite. Retenir une information qui vous ferait reconsidérer notre intervention.
Ce que ça veut dire
Nous adoptons vos outils, vos rituels et vos standards quand ils fonctionnent. Le format de collaboration s’ajuste à votre organisation.
Ce que ça nous interdit
Imposer notre méthode à une équipe qui a la sienne. Quand nous suggérons un changement de pratique, nous le motivons et c’est vous qui tranchez.
Six différences concrètes, formulées de façon vérifiable.
Des années d’ingénierie sur des systèmes complexes. Vous ne financez pas une montée en compétence sur votre projet.
Nous choisissons la solution la plus simple qui tienne dans la durée. Une architecture surdimensionnée coûte deux fois : à la construction, puis à chaque évolution.
Pas de catalogue d’offres à écouler, pas de consultants à placer. Le format s’ajuste à votre besoin, y compris quand cela nous rapporte moins.
Pas de strate entre vous et l’ingénieur. Ce que vous demandez le matin n’a pas besoin de trois relais pour être compris.
Un arbitrage technique se tranche dans l’échange, pas en comité. C’est l’avantage structurel d’une petite organisation, et il disparaît avec la taille : nous en profitons pendant qu’il existe.
Régie ou forfait, mission courte ou accompagnement long, préavis de quinze jours. Vous n’êtes engagé que tant que la collaboration vous sert.
Quatre principes qui gouvernent nos arbitrages techniques. Ils expliquent mieux que n’importe quel discours ce que vous obtiendrez en travaillant avec nous.
Devant deux options qui répondent au besoin, nous prenons la plus simple — même si l’autre est plus intéressante à construire. La complexité est un coût récurrent : elle se paie à chaque nouvelle fonctionnalité, à chaque arrivée dans l’équipe, à chaque incident de production.
Les hypothèses de performance sont presque toujours fausses. Avant de retoucher un système lent, nous l’instrumentons. La cause réelle est rarement celle que tout le monde soupçonne, et optimiser au mauvais endroit ajoute de la complexité sans résultat.
Certains choix sont difficiles à défaire : un modèle de données, une frontière entre domaines, un fournisseur cloud. Nous les identifions tôt et nous y consacrons le temps nécessaire. Les autres, nous les prenons vite, quitte à les corriger — hésiter longuement sur un choix réversible coûte plus cher que de se tromper.
Chaque décision structurante est consignée avec son contexte, les options écartées et leurs raisons. Ce document sert à votre équipe quand nous ne serons plus là — et il nous sert à nous, six mois plus tard, quand nous aurons oublié pourquoi nous avions tranché ainsi.
Hconsul est une jeune structure. Ce qui suit décrit non pas une culture d’entreprise établie, mais les principes de travail que nous appliquons dès aujourd’hui et sur lesquels nous construisons.
Chaque mission commence par des ateliers avec vos équipes métier et techniques, la lecture du code existant et l’examen des incidents passés. Nous n’écrivons pas une ligne avant d’avoir reformulé le problème par écrit et obtenu votre accord sur cette reformulation.
Une veille technique régulière, des expérimentations menées sur nos propres projets, une remise en question des choix passés. Un ingénieur qui ne se forme plus perd son avantage en trois ans.
Documentation, revues de code partagées, montée en compétence de vos équipes. Nous cherchons à ce que vous puissiez vous passer de nous. C’est contre-intuitif commercialement — c’est aussi ce qui fait qu’on nous rappelle.
Nous en ferons. Ce qui compte est le délai entre l’erreur et son signalement. Nous préférons une conversation difficile en semaine trois à une crise en semaine douze.
Une mission réussie n’est pas une mission facturée. C’est un système en production qui fait ce qu’il doit, une équipe capable de le maintenir, et un client qui nous rappelle pour le sujet suivant.
Notre trajectoire n’est pas la croissance rapide. Une société de conseil qui grandit plus vite que sa capacité à recruter au bon niveau dégrade mécaniquement ce qu’elle vend. Nous préférons refuser des missions.
Nos premières réalisations, avec des clients qui acceptent de travailler avec une jeune structure en échange d’engagements contractuels plus favorables que ceux du marché. Ces conditions ne dureront pas ; elles sont notre façon de compenser l’absence de références.
Un réseau restreint d’ingénieurs expérimentés partageant notre exigence. Le critère de sélection n’est pas la disponibilité mais le niveau : nous préférons décliner plutôt que de placer.
Une pratique du conseil informatique plus honnête. Publier ce que nous apprenons, y compris nos erreurs. Dire non quand c’est justifié. Écrire des engagements que nous tenons plutôt que des promesses que personne ne vérifie.
Nos premiers clients ne seront pas des lignes dans une liste de références. Ce sont eux qui feront exister cette société. Nous en aurons conscience à chaque décision.
Vous avez un projet à lancer, une application qui vous bloque, une décision d’architecture à trancher ou une équipe à renforcer. Décrivez-nous votre situation : nous répondons par une analyse, pas par une plaquette. Vous repartez avec notre lecture écrite de votre problème, que vous poursuiviez avec nous ou non.
Hconsul · Île-de-France · RCS Nanterre 994 546 828 · {{EMAIL_CONTACT}}