Architecture et charge
Les choix de conception sont-ils motivés, où se trouvent les goulets d'étranglement, que se passe-t-il quand le volume de commandes triple pendant une opération commerciale ou les soldes.
Un logiciel qui tourne depuis six ans finit par ressembler à une maison agrandie trois fois sans plan : cela tient debout, mais plus personne ne sait ce qui porte quoi. Nous ouvrons le capot d'une application que nous n'avons pas écrite, en lecture seule, et nous répondons à trois questions simples : tient-elle la charge qui arrive, une autre équipe pourrait-elle la reprendre, combien coûterait la remise en ordre ? Exemple : un transporteur régional dont l'outil de suivi des tournées a été développé par un prestataire aujourd'hui injoignable.
Nous jugeons sur des critères annoncés à l'avance, pas sur des goûts personnels : tenue à la charge, facilité d'entretien, sécurité, capacité à survivre au départ d'une personne.
Les choix de conception sont-ils motivés, où se trouvent les goulets d'étranglement, que se passe-t-il quand le volume de commandes triple pendant une opération commerciale ou les soldes.
Lisibilité, couverture par des tests automatisés, morceaux dupliqués, chemin qu'emprunte une correction avant d'arriver en production, existence d'une documentation exploitable par un nouvel arrivant.
Bibliothèques abandonnées, composants portant des vulnérabilités publiées, versions de PHP, de Node.js ou de framework sorties du support de l'éditeur.
Liens avec Sage, Cegid ou Pennylane, plateforme de facturation électronique, passerelles Stripe ou PayPlug, suivi Colissimo ou Chronopost. Nous regardons surtout ce qui se produit quand l'interface distante renvoie une erreur ou cesse de répondre.
Où tournent les serveurs, où reposent les fichiers clients, ce que prévoient les contrats de sous-traitance et si la configuration tient la route face au registre des traitements en cas de contrôle de la CNIL.
Quelqu'un d'autre que l'auteur peut-il reprendre l'application, ou bien tout tient-il dans la mémoire d'un développeur et dans un dépôt hébergé sur son compte personnel.
Constats classés par gravité, conséquence métier expliquée pour chacun, ordre de grandeur du coût de correction, relecture commune en visioconférence.
La durée dépend de la taille de l'application et du nombre d'intégrations ; elle est annoncée avant le démarrage. Nous travaillons avec des accès en lecture seule.
Rachat, changement de prestataire ou simple évaluation du risque. L'objectif décide des zones examinées de près et du niveau de détail du rapport.
Dépôt de code, documentation, console d'hébergement, journaux, tickets ouverts. Nous parlons aussi à l'équipe en visioconférence, car une part du savoir n'a jamais été écrite.
Chaque critère est apprécié séparément et chaque constat est accompagné de ce qu'il implique concrètement pour l'activité.
Rapport remis puis parcouru ensemble, hiérarchisé du plus grave au plus secondaire, avec un chiffrage par correction.
Le pire constat n'est presque jamais un code mal écrit. Un logiciel inélégant peut rendre service pendant dix ans. En revanche, quand un seul développeur comprend la mécanique et que rien n'est documenté, l'entreprise négocie en position de faiblesse à chaque renouvellement de contrat. Nous relevons cette dépendance à part, indépendamment de la qualité technique du reste.
Beaucoup de choses : comportement de l'application, temps de réponse, configuration publiée, structure de la base si vous y avez accès, journaux d'erreurs, contrats et factures. Le rapport sera plus court et signalera clairement ce qui n'a pas pu être vérifié. L'absence d'accès aux sources est d'ailleurs un constat en soi ; il vaut la peine de relire ce que dit votre contrat sur la propriété du code.
Oui. Dans ce cadre nous regardons ce qui pèse sur la valeur : côté technique des licences open source embarquées, l'analyse juridique restant chez votre avocat, dette accumulée, dépendance à quelques personnes et coût d'exploitation une fois l'opération faite. Le calendrier est calé sur celui de votre conseil.
Nous décrivons un état et des risques, nous ne notons personne. Dans les faits les équipes y gagnent souvent : des arguments qu'elles répètent depuis deux ans finissent par être entendus parce qu'ils viennent de l'extérieur.
Une application de taille moyenne demande généralement de une à trois semaines selon le nombre d'intégrations. Nous travaillons au taux de 95 € HT/h, ou au forfait annoncé après un premier échange en ligne, une fois le périmètre connu.
Nous l'écrivons, avec le raisonnement et deux chiffrages : réparation progressive ou réécriture. La décision vous appartient, elle est simplement plus solide quand elle repose sur des montants que sur une impression.
Décrivez l'application et la raison de l'audit. Vous recevez un rapport où les risques sont rangés du plus sérieux au plus mineur.
Votre demande nous est parvenue
Vous recevrez une réponse sous un jour ouvré. Si vous signalez une panne qui immobilise vos équipes, elle passe en priorité.
Cette ville ne figure pas dans la liste. Vérifiez l'orthographe ou choisissez la grande ville la plus proche : nous travaillons à distance, cela ne change rien au périmètre de nos prestations.