Vos dépendances, à jour chaque mois
Chaque application repose sur des centaines de paquets open source. Des correctifs de sécurité sortent chaque semaine, et les mises à jour majeures s'accumulent jusqu'à devenir un projet en soi. Nous prenons ce travail en charge : des pull requests testées, un rapport mensuel et un plan pour les grosses mises à jour, pour un forfait mensuel plutôt qu'un recrutement.
Le problème que nous prenons en charge
- Des PR de robots que personne ne fusionne. Dependabot et Renovate proposent les mises à jour, mais chacune demande quelqu'un pour lire le changelog, lancer l'application et fusionner. Elles restent ouvertes des mois, et les correctifs de sécurité avec elles.
- Des versions majeures qu'on repousse. Un robot ne fait pas une migration de version majeure. Quand une faille n'est corrigée que dans la version suivante, le correctif devient une migration, et personne n'en est responsable.
- Des questions sans réponse rapide. « Sommes-nous touchés par cette nouvelle faille ? Quel produit, quelle version ? » Pour répondre, il faut un inventaire à jour de ce que vous livrez.
Comment ça marche
1. Revue initiale
Prix fixe, convenu à l'avance. Nous passons vos dépôts en revue : failles connues dans ce que vous déployez, retard de chaque dépendance, paquets abandonnés ou dépréciés, PR de robots en attente. Vous recevez un rapport écrit avec un plan priorisé, que vous gardez, que vous continuiez ou non.
2. Maintenance mensuelle
Chaque mois : correctifs de sécurité et mises à jour sous forme de petites PR testées, que votre équipe n'a plus qu'à relire ; les PR de robots relues, testées, puis fusionnées ou expliquées ; une étape de migration planifiée à la fois pour les versions majeures ; un court rapport de ce qui a changé et de la suite.
3. Quand une faille tombe
Quand une faille critique touche ce que vous livrez, nous vous prévenons avec les dépôts et versions concernés, et un correctif en PR, avant qu'un scanner ou un client ne vous l'apprenne.
Le règlement européen sur la cyberrésilience (CRA)
Depuis le 11 septembre 2026, les fabricants de logiciels vendus dans l'UE doivent signaler à l'ENISA les failles activement exploitées dans les 24 heures, et l'ensemble des obligations s'applique dès décembre 2027, dont une nomenclature logicielle (SBOM) pour chaque produit et un processus documenté de gestion des vulnérabilités. En option, nous produisons et tenons à jour le SBOM de chaque version, et assurons la gestion des failles de vos dépendances : surveillance, évaluation, correctifs et registre des actions. Il s'agit d'un appui technique à votre processus, pas d'un conseil juridique.
Notre façon de travailler
- Tout arrive en pull requests dans vos dépôts, par votre circuit de relecture habituel. Aucun accès à la production n'est nécessaire.
- Chaque PR dit ce qui a été vérifié : compilation, types, tests, et ce qui n'a pas pu être testé, avec la raison.
- Nous disons quand une mise à jour n'en vaut pas la peine, ou quand une dépendance doit être remplacée plutôt que corrigée.
- JavaScript et TypeScript (Node.js, Next.js, React) et Python. Autres technologies sur demande.
Notre travail en public
Nous mesurons et publions ce que nous trouvons dans le code d'autrui : applications d'exemple aux dépendances vulnérables, commandes d'installation qui pointent vers des noms de paquets libres et le taux de faux positifs de nos propres contrôles (pages en anglais). Des correctifs que nous avons proposés ont été fusionnés par des projets comme NVIDIA SkillSpector, OpenHands et Countly.
Commencer par une revue
Écrivez à presendapp@gmail.com avec le lien vers vos dépôts (ou une courte description s'ils sont privés). Nous répondons avec le contenu de la revue initiale et son prix fixe.