Audit technique
Vous vous apprêtez à engager de l'argent sur une application ou un site dont l'état reste incertain. Un audit technique le relève, puis range ce qu'il a trouvé dans l'ordre où vous devrez le traiter.
d'expérience
missions réalisées
projets en activité
sur-mesure
Un audit de votre site ou de votre application, avant d'engager la dépense
Vous préparez une dépense sur votre outil. Vos équipes réclament une fonction, un partenaire demande un accès, un écran que vos utilisateurs contournent depuis longtemps doit changer. Vous savez ce que ce projet doit rapporter à votre activité. Reste à savoir si l’application en place le supportera, et cette réponse manque à votre entreprise.
Deux personnes peuvent vous répondre, et la réponse engage les deux. Celle qui a construit l’application juge son propre travail. Celle qui aimerait la refaire chiffre le chantier qu’elle vous propose. Vous recevez deux verdicts opposés sur le même code, et votre entreprise manque du moyen de les départager.
La question se pose rarement au calme. Elle arrive avec un budget déjà voté, un acquéreur déjà en discussion, une équipe qui attend une réponse cette semaine. Le temps de l’instruire correctement manque au moment précis où elle décide du montant engagé.
Votre comptabilité chiffre ce que l’outil vous coûte. Vos équipes décrivent ce qu’il leur fait perdre. Sa capacité à porter votre prochain projet relève, elle, d’une lecture du code et des données, que personne n’a commandée jusqu’ici.
Cette lecture se commande, et elle se commande seule, avant tout chantier. Nous ouvrons le code, la base, l’hébergement et les comptes, puis nous écrivons ce que nous y trouvons dans les termes où vous prenez vos décisions. Nous la rendons avant que vous choisissiez entre reprendre, refondre ou moderniser, et nous concluons parfois qu’il suffit de garder l’outil en l’état. Nous menons nous-mêmes ces chantiers de refonte, et le chiffrage de chaque option, garder l’outil comme le refaire, reste écrit dans le rapport, sous vos yeux plutôt que sous les nôtres. Ce rapport reste à vous, utilisable par l’équipe de votre choix, la nôtre ou une autre, pour engager la suite.
Les moments où un dirigeant fait auditer son application ou son site
Chacune de ces situations amène le même dirigeant à la même question.
Le budget est voté, le besoin est écrit, et personne ne garantit que l'outil en place tiendra ce que vous allez lui demander.
Aucun des deux ne vous montre sur quoi il se fonde, et vous devez trancher avant que le projet parte.
L'activité a repris, la panne est réparée, et rien ne vous dit aujourd'hui qu'elle ne reviendra pas le mois prochain.
Un acquéreur, un investisseur ou votre direction de groupe demande un document technique que vous n'avez jamais produit.
Le refus tombe sans démonstration. Vous voudriez savoir s'il décrit l'application ou s'il arrange celui qui l'énonce.
Dans ces cinq cas, vous cherchez la même chose : une lecture de votre outil produite par une équipe extérieure au chantier qui pourrait suivre. Nous décrivons la marche à suivre pour faire auditer son site ou son application, du premier accès jusqu’à la remise.
Audit technique de site web ou d'application : nos six points de contrôle
Nous ouvrons les six, ou seulement ceux qui portent votre décision.
Le code et sa construction
Nous lisons comment l'application est bâtie, ce que vos écrans font vraiment quand un dossier les traverse, et ce qu'ajouter une fonction y demande aujourd'hui. Un audit de code avant reprise de projet s'arrête à ce seul point quand c'est la question qui vous occupe.
La base et les données accumulées
Nous regardons comment vos dossiers sont rangés et ce qu'ils gardent d'utilisable après des années d'activité. Les doublons, les champs détournés de leur usage d'origine et les historiques incomplets se relèvent ici, avec le travail que leur remise en ordre demanderait.
L'hébergement, les comptes et les accès
Nous remontons où tourne votre outil, qui paie quoi, à quel nom chaque compte a été ouvert et ce que vous récupérez si la relation avec votre prestataire s'arrête demain.
Ce que votre outil appelle à l'extérieur
Envoi de courriels, paiement, signature, connexion à votre comptabilité : nous listons ces services et ce qui s'arrête chez vous si l'un d'eux cesse de répondre.
La vitesse réelle chez vos visiteurs
Nous chronométrons vos pages principales chez vos visiteurs et nommons ce qui les alourdit. Un audit de performance d'un site reprend ce point page par page et chiffre ce que l'attente vous coûte.
Les droits d'accès et l'exposition des données
Nous vérifions qui atteint quoi et par quels chemins, comptes d'anciens salariés compris. Un audit de sécurité d'une application pousse ce point jusqu'aux tentatives d'accès réelles.
Nos dernières réalisations
Toutes nos réalisationsNous avons aidé des dizaines de clients dans leur transformation digitale
Commandez le diagnostic avant d'engager le chantier
Écrivez-nous ce que vous hésitez à engager cette année, nous vous répondons avec les points à ouvrir et le délai du rapport.
Comment nous conduisons cet audit
-
Nous écrivons avec vous, en une phrase, la question à laquelle le rapport devra répondre. Un outil à présenter à un acquéreur et un outil qui doit absorber une fonction nouvelle n'appellent pas la même profondeur. Cette phrase fixe les points de contrôle que nous ouvrons.
-
Nous récupérons le code, la base et les comptes, puis nous faisons tourner un exemplaire de votre outil en dehors de votre production. Deux mesures restent prises en lecture sur votre outil réel, le temps d'affichage et la charge d'une journée ordinaire, qui perdraient leur sens ailleurs. C'est l'étape qui varie le plus d'un client à l'autre. Quand tout est disponible, elle passe vite. Quand il faut retrouver un mot de passe chez un ancien prestataire ou remonter un serveur à l'identique, elle occupe la plus grande part de la mission.
-
Nous passons du temps avec les personnes qui ouvrent l'outil tous les jours. Elles donnent ce qu'aucune lecture de code ne produit : les opérations qui reviennent, celles qu'elles ont appris à éviter, les tableurs qu'elles tiennent à côté.
-
Nous chiffrons chaque correction relevée, y compris celles que nous vous déconseillons d'engager, et nous écrivons ce qui motive chaque déconseil. Un défaut sans son coût en face reste une opinion, que vous ne pourriez ni inscrire à un budget ni mettre en concurrence.
-
Nous réunissons dans la même séance vous et ceux qui manipulent l'outil, et nous présentons les conclusions devant les deux. Vous posez vos questions à ce moment, y compris celles qui contestent ce que nous avançons. Le rapport est remis à cette séance, dans sa version définitive.
Faire auditer son outil : les points à régler avant de démarrer
Trois éléments, et le premier compte plus que les deux autres. Le code, sous la forme où vous le détenez, même incomplet et même sans savoir s’il correspond à ce qui tourne. Les accès à l’hébergement et à la base, ou à défaut le nom des personnes qui les détiennent. Une heure avec quelqu’un qui se sert de l’outil tous les jours. Ce qui manque au départ déplace une partie de notre travail vers sa recherche, et nous vous le disons avant de commencer.
.Vous décidez, et les deux cas fonctionnent. Le prévenir raccourcit la remise en route, puisqu’il ouvre les accès que nous devrions autrement reconstituer un par un. Garder la discrétion vous laisse la main sur le calendrier de vos discussions avec lui, et nous travaillons alors avec ce que vous détenez déjà. Nous le contactons uniquement si vous nous le demandez. Le rapport porte sur l’état de l’outil et sur ce qu’il en coûte de le faire évoluer, jamais sur la manière de travailler de celui qui vous a livré.
.Comptez plusieurs semaines pour une revue des six points de contrôle. Deux choses commandent cette durée, et le volume du code arrive loin derrière elles. La première est la disponibilité des accès. La seconde est celle de vos équipes pour les entretiens, parce qu’une partie de ce que nous cherchons vit dans leur tête. Un examen concentré sur un seul point suit son propre calendrier, plus court quand il reste en surface, plus long dès qu’il descend jusqu’aux essais. Nous datons la remise une fois le périmètre arrêté.
.Oui. Le découpage passe par votre décision plutôt que par un module de l’application. Vous voulez ouvrir votre outil à vos clients : nous regardons les droits d’accès, l’exposition des données et ce que votre outil appelle à l’extérieur, et nous laissons de côté la façon dont vos règles de calcul sont écrites. Nous délimitons ce périmètre avec vous avant de commencer, et le rapport dit ce qu’il a laissé de côté. Une conclusion sur un point resté fermé vous ferait décider sur du vide.
.Nous en couvrons la part technique et nous nous arrêtons là. Les temps d’affichage que nous relevons comptent dans le classement, sans le décider à eux seuls, et nous vérifions que votre site répond correctement aux robots. Ce qu’un moteur découvre, explore et retient de vos adresses relève d’un audit SEO technique, mené par notre branche visibilité. Les deux se commandent ensemble sur un site public, avec deux périmètres séparés.
.L’analyse porte sur une copie. Nous convenons au départ de sa durée de vie chez nous et de ce que nous en faisons à la remise du rapport. Deux mesures échappent à cette copie parce qu’elles perdraient leur sens ailleurs, le temps d’affichage réel et la charge d’un jour ordinaire : nous les prenons sur votre outil tel qu’il tourne, en lecture. Quand vos dossiers contiennent des informations qui doivent rester chez vous, deux montages fonctionnent : une copie dont les noms et les coordonnées sont remplacés avant de nous parvenir, ou un accès distant à un exemplaire qui reste sur votre hébergement. Dites-nous ce que vos données contiennent, nous vous dirons lequel s’impose.
.Le périmètre d'un audit technique et la décision qu'il prépare
Trois questions qui relèvent d’un autre travail que l’audit
Un audit établit ce que votre outil fait, ce qu’il coûte de le modifier, et ce qui risque de céder. Trois questions voisines lui échappent, et les confondre mène à commander la mauvaise prestation.
La première est l’opportunité commerciale. Savoir si la fonction que vous voulez ajouter rapportera quelque chose relève de votre marché. Nous chiffrons ce qu’elle coûte, vous seul chiffrez ce qu’elle rend.
La deuxième est l’ergonomie. Un écran que vos utilisateurs détestent peut être écrit proprement, un écran qu’ils adorent peut reposer sur une construction qui cédera à la prochaine montée en charge. Les deux sujets se traitent chez nous, par deux méthodes et deux interlocuteurs.
La troisième est le choix d’un produit du marché. Nous traitons la part qui porte sur ce que vous quitteriez, le reste demande d’éprouver le produit candidat sur vos propres dossiers. Cette comparaison tourne parfois en faveur de ce que vous avez déjà, à condition d’en remettre le socle à niveau : c’est alors une modernisation d’un outil vieillissant qui s’ouvre, chiffrée à partir du rapport.
L’ordre des corrections est la partie que vous achetez
Des outils d’analyse existent et ils sont accessibles à tous. Lancés sur une application, ils produisent une longue liste où l’anomalie qui bloquera votre prochaine évolution voisine avec la remarque de forme que personne ne corrigera jamais.
Le dirigeant qui reçoit cette liste se retrouve devant le problème qu’il voulait résoudre, avec plus de pages. Il lui manque encore par où commencer, ce que chaque ligne coûte, et de quoi défendre un budget devant ses associés.
Ce tri est notre part du travail. Nous marquons les lignes dont la correction coûterait plus qu’elle ne rapporte, elles restent au rapport avec ce jugement écrit en face, et nous rangeons les autres selon ce qu’elles vous coûtent de laisser en place. Vous lisez alors trois ensembles sans compétence technique : ce que vous engagez ce trimestre, ce que vous inscrivez au budget suivant, ce que vous gardez en l’état en connaissance de cause.
L’avis de celui qui a construit votre outil, et comment le recouper
L’équipe qui a développé votre application connaît son contenu mieux que quiconque. Son avis est une matière première, à condition de lui poser les questions dont la réponse se vérifie ailleurs.
Une question sur l’état général de l’outil produit une opinion. Demandez plutôt combien de temps a pris la dernière mise en service, combien de fois l’application s’est arrêtée cette année, et combien de temps il faut pour la remettre en route sur une machine neuve. Ces trois réponses se recoupent avec ce que nous relevons de notre côté.
Quand elles concordent, nous resserrons l’audit sur la question qui reste ouverte. Quand elles divergent, l’écart nous indique le point à reprendre en premier. Ce qui vous renseigne est le rapprochement des deux sources, jamais l’une des deux prise seule.
Ce qui fait vieillir un rapport d’audit
Un rapport décrit un outil à une date. Sa durée de validité tient au mouvement autour de lui plus qu’au calendrier.
Votre activité bouge en premier. Une nouvelle offre, un partenaire à raccorder, et la question que le rapport tranchait cesse d’être celle que vous vous posez. Vient ensuite le travail mené sur l’outil entre-temps : chaque livraison d’un prestataire déplace une partie de ce que nous avions relevé, et un rapport qu’une série de développements a suivi décrit un outil qui a bougé.
Reste ce que votre outil ne maîtrise pas. Les composants publics sur lesquels une application s’appuie reçoivent des correctifs pendant des années, puis cessent d’en recevoir, sur un calendrier extérieur à votre entreprise. C’est la partie du rapport à relire en premier quand vous le rouvrez, et nous vous disons à la remise laquelle vieillira le plus vite chez vous.
Ce qui vous reste de l’audit, quel que soit son verdict
Ce risque ne doit pas verrouiller la conclusion inverse : votre outil tient, la fonction que vous vouliez ajouter s’y ajoute pour un montant raisonnable, et le budget de refonte que vous commenciez à provisionner part ailleurs.
Cette conclusion vous évite de refaire quelque chose qui fonctionnait, et le temps que ce chantier aurait pris, et elle vous donne de quoi répondre à celui qui vous poussait vers le chantier. C’est pour la garder possible que l’audit se commande et se facture seul.
Le document qui sort vous appartient entièrement, et vous restez libre de la suite. Notre engagement porte sur son contenu : ce que nous avons ouvert y figure, ce que nous avons laissé de côté y figure aussi, et l’ensemble est écrit assez clairement pour qu’une autre équipe le reprenne au mot.