Ce que nous avons expédié en janvier 2026

Janvier a été un mois bien rempli. Nous avons déployé une série de mises à jour pour Firma.dev dont nous sommes particulièrement fiers, et la plupart d'entre elles proviennent directement des retours que nous avons reçus des développeurs qui s'intègrent à l'API.

Le thème de ce mois-ci était de rendre l'API plus rapide, plus flexible et plus facile à intégrer. Certains de ces changements sont de petites améliorations pour simplifier la vie au quotidien. D'autres ouvrent la voie à des flux de travail entièrement nouveaux. Nous en sommes maintenant à la version 1.2.0, et toutes ces nouveautés sont disponibles dès aujourd'hui.

Voici le récapitulatif.

Des demandes de signature 40 % plus rapides

Nous avons passé quelques semaines à analyser les performances et avons réussi à réduire notre temps de latence moyen pour les demandes de signature de 820 ms à environ 500 ms. Cela représente une amélioration d'environ 40 % sur l'ensemble du système.

Les modifications ont principalement porté sur l'infrastructure. Nous avons optimisé certaines requêtes de base de données qui étaient devenues inefficaces avec le temps, et nous avons placé les actifs statiques derrière AWS CloudFront pour la mise en cache en périphérie (edge caching). Rien de révolutionnaire, mais c'est le genre de travail dont les bénéfices se cumulent.

Si vous intégrez des signatures dans votre produit, cela a plus d'importance qu'il n'y paraît. Une latence de 300 ms ne semble pas énorme, mais c'est la différence entre un flux de signature qui semble instantané et un autre qui paraît lent. Des réponses plus rapides signifient moins de parcours abandonnés et moins de frictions pour vos utilisateurs.

Demandes de signature ponctuelles (sans modèle requis)

Auparavant, si vous vouliez envoyer un document pour signature via Firma.dev, vous deviez d'abord créer un modèle. Cela faisait sens pour des flux de travail répétitifs comme les contrats de travail ou les accords de confidentialité (NDA), mais cela ajoutait des étapes inutiles pour des documents uniques.

Désormais, vous pouvez vous passer complètement de modèle. Téléversez directement un PDF, définissez vos champs et vos destinataires en ligne, et envoyez-le. Un seul appel API, aucune création de modèle n'est requise.

C'est très utile pour les accords ponctuels, les contrats uniques ou toute situation où vous n'allez pas réutiliser la structure du document. Vous bénéficiez toujours des mêmes types de champs, options de signataires et suivi. Vous n'avez simplement pas besoin de configurer un modèle au préalable.

Consultez le point de terminaison de création de demande de signature pour les détails d'implémentation.

Point de terminaison atomique de création + envoi

En parlant de réduction des appels API : nous avons ajouté un nouveau point de terminaison atomique qui vous permet de créer et d'envoyer une demande de signature en un seul appel.

Auparavant, vous deviez appeler le point de terminaison de création, puis appeler celui d'envoi. Deux requêtes, deux allers-retours. Le nouveau point de terminaison /signing-requests/create-and-send combine les deux en un seul.

Mais le véritable avantage réside dans l'intégrité transactionnelle. Le point de terminaison valide l'ensemble des données avant de créer quoi que ce soit. Si un élément échoue à la validation, rien n'est créé et vous n'êtes pas facturé. Les crédits ne sont déduits qu'une fois la demande de signature créée avec succès et les e-mails envoyés.

Extrait de la documentation : « Un seul appel API au lieu de deux requêtes distinctes... Déduction atomique des crédits – facturation uniquement si tout réussit. »

Si vous créez des automatisations ou des flux de travail à grand volume, ce point de terminaison est plus propre et plus fiable que le chaînage de deux appels.

Champs en lecture seule

Vous pouvez désormais marquer des champs comme étant en lecture seule lors de la création ou de la mise à jour d'une demande de signature. Il s'agit de champs qui s'affichent sur le document avec des valeurs pré-remplies, mais que le signataire ne peut pas modifier.

C'est utile pour des éléments tels que les montants des contrats, les numéros de référence, les totaux calculés ou les identifiants d'employés. Tout ce que le signataire a besoin de voir pour le contexte mais ne doit pas pouvoir modifier.

Vous trouverez la propriété read_only dans le point de terminaison de mise à jour complète. Définissez-la sur true pour n'importe quel champ de texte, et il deviendra visible mais non modifiable.

Contrôles précis sur les e-mails

Nous avons ajouté quatre nouveaux paramètres qui vous donnent un contrôle granulaire sur les e-mails que Firma.dev envoie en votre nom :

• send_signing_email – la notification initiale « veuillez signer ce document »

• send_finish_email – la confirmation « signature terminée »

• send_expiration_email – le rappel lorsqu'une demande est sur le point d'expirer

• send_cancellation_email – la notification lorsqu'une demande est annulée

Ces quatre paramètres sont définis sur true par défaut, de sorte que les intégrations existantes fonctionnent exactement comme avant. Mais si vous souhaitez envoyer vos propres e-mails personnalisés à votre marque plutôt que les nôtres, vous pouvez désormais désactiver l'un ou l'ensemble de ces paramètres et gérer les notifications vous-même.

Cela s'associe parfaitement aux paramètres de marque blanche ci-dessous.

Ignorer les conditions d'utilisation de Firma.dev pour une marque blanche totale

Il y a un nouveau paramètre dans votre espace de travail appelé « Exiger l'acceptation des conditions d'utilisation ». Lorsqu'il est activé (par défaut), les signataires doivent accepter les conditions d'utilisation de Firma.dev avant de signer. Lorsque vous le désactivez, cette étape disparaît complètement.

Ceci est conçu pour les équipes qui souhaitent une expérience de signature entièrement en marque blanche. Vos signataires voient votre marque, vos e-mails (si vous avez désactivé les nôtres) et vos conditions d'utilisation. Firma.dev reste invisible.

Si vous choisissez cette option, nous vous recommandons d'avoir vos propres conditions générales en place. Vous assumez la responsabilité d'informer les signataires des implications juridiques de leur signature, assurez-vous donc que vos propres conditions générales couvrent ce point.

Combiné avec les contrôles d'e-mail ci-dessus, vous pouvez désormais proposer une expérience de signature entièrement personnalisée à votre image, sans qu'aucune interface de Firma.dev ne s'affiche à vos utilisateurs finaux.

Nouveaux guides pour les développeurs

Nous avons réécrit une grande partie de notre documentation ce mois-ci. Trois nouveaux guides ont été mis en ligne :

Guide d'authentification – Couvre l'authentification par clé API pour les requêtes de serveur à serveur, ainsi que les jetons JWT pour intégrer les éditeurs de modèles et de demandes de signature dans votre application. Comprend également le nouveau flux de rotation des clés API avec des périodes de grâce de 24 heures.

Guide des limites de taux – Documente tous les niveaux de limites de taux (200 requêtes/min pour les lectures, 120/min pour les écritures, etc.). Note importante ici : les limites de taux s'appliquent par espace de travail, et vous pouvez avoir un nombre illimité d'espaces de travail sur votre compte. Cela vous offre une extensibilité horizontale virtuellement illimitée. Si, pour un cas d'utilisation spécifique, vous avez besoin de limites encore plus élevées, contactez le support et nous pourrons les augmenter, mais les valeurs par défaut sont déjà conçues pour des volumes très importants.

Guide de configuration complète – Un guide complet de bout en bout, de la création de compte à la signature intégrée. Couvre les espaces de travail, les modèles, les demandes de signature, les éditeurs intégrés, les webhooks et la gestion des crédits. Si vous débutez, c'est par ici qu'il faut commencer.

Gestion complète des versions de l'API

Nous avons introduit un système formel de gestion des versions ce mois-ci. L'API utilise désormais un routage des versions basé sur l'en-tête via X-API-Version, et nous en sommes actuellement à la v1.2.0.

En résumé : nous nous engageons à ne pas bloquer ou casser votre intégration. Extrait du guide des versions : « Les changements majeurs (breaking changes) ne sont introduits que lors des incrémentations de versions majeures... Les changements mineurs non bloquants, tels que de nouveaux champs optionnels ou de nouveaux points de terminaison, ne nécessitent pas de nouvelle version. »

Lorsque nous sortirons un jour la v2, l'ancienne version ne disparaîtra pas d'un coup. Vous recevrez des avertissements d'obsolescence (deprecations) dans les en-têtes de réponse pendant au moins six mois avant que la version ne soit retirée. Les en-têtes suivent la RFC 8594, donc si vous vérifiez déjà les en-têtes Deprecation et Sunset dans d'autres API, vous saurez à quoi vous attendre.

Pour l'instant, la v1 est active et aucune obsolescence n'est planifiée. Tout ce que nous avons déployé ce mois-ci s'ajoute à l'existant, de sorte que votre intégration actuelle continue de fonctionner sans modification.

Pour conclure

Voilà pour le mois de janvier. Beaucoup de petites et moyennes améliorations qui s’additionnent pour former une API plus performante et plus flexible.

Les tarifs n'ont pas changé. C'est toujours €0,049 par enveloppe, payé à l'usage, sans minimum. Si vous n'avez pas encore essayé Firma.dev, vous pouvez faire des tests gratuitement avec de vrais documents, sans limites, et ne payer que lorsque vous passez en production.

Nous allons continuer à déployer des nouveautés. S'il y a quelque chose que vous aimeriez voir dans l'API, faites-le nous savoir.

Commencer gratuitement – aucune carte de crédit requise.