DEV Community: Anthony Leignel

How Many Obsolete Dependencies Are You Using Without Knowing It? An Open Source Checker

Anthony Leignel — Sun, 16 Aug 2026 15:50:57 +0000

Security also starts with what we install

We install Python packages, VS Code extensions, tools that help us save time, test an idea, or simply improve our development environment.

Then we move on.

A few months or years later, some of those projects have been deprecated, archived, renamed, or are simply no longer maintained.

And they are still installed.

That is exactly the problem I wanted to address with Dependency Security Checker, an open source tool that locally scans installed Python packages and VS Code extensions, then compares them against documented alert databases.

The project is open source and available here:

Dependency Security Checker, GitHub

An alert before a vulnerability becomes your problem

The goal is not to claim that a dependency is vulnerable simply because it is no longer maintained.

That would be incorrect.

The goal is much simpler: to warn you.

If an installed package has officially been deprecated, you should be able to know about it.

If a VS Code extension you still use has been archived, you should be able to know that too.

And if a project has been renamed or its maintainers now recommend an alternative, that information should be easy to find.

A tool that does not make decisions for you

Dependency Security Checker does not uninstall anything, disable anything, update anything, or modify your projects.

It scans, detects, and displays the available information:

[!] package-name 1.0.0
    Status / Statut: DEPRECATED / DÉPRÉCIÉ

    Reason:
    ...

    Raison :
    ...

    Suggested replacement / Remplacement suggéré: ...

    Source: ...

From there, the decision is yours.

You can check the source, understand why the project was flagged, review how you use it, and decide whether it should be kept, replaced, updated, or removed.

This approach matters because a security-related tool should not create another problem by automatically modifying an environment it does not fully understand.

Deprecated does not mean vulnerable

This is probably the most important distinction behind the project.

An abandoned dependency is not automatically vulnerable.

Likewise, the absence of an alert does not mean a dependency is secure or free from vulnerabilities.

But when a project is no longer maintained, one question becomes legitimate:

Who will fix the next vulnerability if one is discovered?

This is where dependency maintenance becomes directly relevant to security.

Vulnerabilities do not only come from the code we write ourselves, they can also exist in the different components we add to our environments and projects.

With the number of packages, libraries, extensions, and development tools a modern environment can accumulate, it becomes increasingly difficult to remember exactly what is still installed and whether every component is still maintained.

Why is it open source?

Because when it comes to security, I prefer being able to see what a tool actually does.

Dependency Security Checker runs locally, its alert databases are visible, its sources can be checked, and its behavior can be inspected directly in the code.

It does not need to send your list of packages or VS Code extensions to a remote service to perform the scan.

Today, with software failures, compromised dependencies, abandoned projects, and supply-chain security issues becoming increasingly difficult to ignore, security should not be treated as something we think about only after a problem occurs.

Making the project open source also means something important:

You do not have to simply trust the tool.

You can inspect it.

You can verify its data.

You can contribute.

You can report incorrect information or submit another officially deprecated or abandoned dependency with a public source.

You do not need to be a developer to understand the result

I also wanted to avoid building something that only makes sense to someone who spends every day working in a terminal.

A developer can use it as a quick check of their environment, but a less technical user can also run the checker and understand the essential result.

No known alert found, nothing installed matched the current database.

An alert appears, something deserves your attention.

Then you get the status, the reason, a suggested replacement when one exists, and most importantly, the source.

No mysterious score.

No invented risk level.

No automatic decision.

The information remains understandable.

A database designed to evolve

The first version already contains hundreds of documented alerts across Python packages and VS Code extensions.

But the database is not intended to pretend it is exhaustive.

New projects will be abandoned.

Others will be archived.

Some libraries will be renamed or replaced.

The project can therefore evolve over time with one simple principle:

An alert should be backed by a source.

The objective is not to build the biggest list possible, but to maintain a database reliable enough for an alert to actually mean something when it appears.

A few seconds to look at what we are using

Software security can become extremely complex.

Here, the principle is intentionally simple.

You run the checker.

It looks at what is installed.

It compares it against its local database.

If it finds something, it tells you.

Then you investigate.

Because before deciding whether a dependency should still be part of your environment, you first need to know that it deserves your attention.

The project is available here:

Dependency Security Checker, GitHub

https://palks-studio.com

Comparing PDF and XML Data Locally with Python, Open Source

Anthony Leignel — Sat, 15 Aug 2026 20:40:01 +0000

A lightweight open source tool for detecting differences between two representations of the same document

A PDF and an XML file can represent the same document while containing different information.

A value may have been modified in one representation, a reference may be missing, a number may use a different format, or some information may simply exist in one file but not the other.

When both files become part of the same workflow, checking them manually can quickly become tedious.

This is why I built PDF / XML Comparator, a small open source Python tool designed to perform a first comparison locally.

View PDF / XML Comparator on GitHub

The problem

PDF and XML serve very different purposes.

The PDF provides a human-readable representation of a document, while XML provides structured data that can be processed by software.

Even when both representations originate from the same process, having two files does not automatically guarantee that every value represented in one can also be found in the other.

For example, you may encounter situations where:

a reference differs between the PDF and XML
an amount was changed in one representation
a value exists only in the XML
information visible in the PDF cannot be found in the XML
equivalent values use different formatting

Opening both files and searching for every value manually works for a single document, but it quickly becomes inefficient when repeated.

A deliberately simple approach

PDF / XML Comparator does not try to understand the business meaning of every field.

Instead, it performs a bidirectional comparison.

The process can be summarized as:

PDF ──► Text extraction ──► Search values in XML
                              │
                              ▼
                         Differences
                              ▲
                              │
XML ──► Data extraction ──► Search values in PDF

https://palks-studio.com

Compare Two PDF Files Locally with Python, Open Source

Anthony Leignel — Wed, 12 Aug 2026 19:41:42 +0000

A lightweight open-source tool for detecting textual differences between PDFs

Comparing two versions of a PDF should not necessarily require uploading documents to an online service.

This is especially true when working with internal documentation, reports, invoices, technical files, or documents that simply should not leave your machine.

I built PDF Comparator, a small open-source Python tool designed for exactly that purpose.

It compares the textual content of two PDF files locally and shows what changed between them.

No AI, no external API, no account, and no document upload.

How it works

The principle is intentionally simple:

PDF A → Text extraction
PDF B → Text extraction → Lightweight normalization → Comparison → Differences

The first PDF is considered the reference version, while the second is the new version.

The tool extracts text from all pages, performs lightweight normalization, then detects added and removed lines.

For example:

--- old.pdf
+++ new.pdf

-Address: 12 Example Street
+Address: 24 Example Street

-Total: €1,200
+Total: €1,350

Instead of manually checking two documents line by line, the differences are immediately visible in the terminal.

Running it

The project only requires Python 3 and pypdf.

Clone the repository and install the dependency:

git clone https://github.com/Palks-Studio/pdf-comparator
cd pdf-comparator

python -m pip install -r requirements.txt

Then compare two PDFs:

python pdf-compare.py old.pdf new.pdf

If no textual difference is found, the tool simply reports that no difference was detected.

Otherwise, the differences are displayed directly in the terminal.

Local by design

One of the main reasons I built this tool was to keep the workflow simple and local.

The PDFs are processed directly on your machine.

There is:

no file upload
no remote server
no external API
no AI processing

For documents containing internal or sensitive information, avoiding an unnecessary external transfer can be just as important as the comparison itself.

What it can be useful for

PDF Comparator can help when reviewing different versions of:

technical documentation
reports
invoices
specifications
administrative documents
generated PDFs
archived documents

It can also be useful during development when a system generates PDFs and you want a quick way to check whether textual content changed between two outputs.

What it does not do

PDF Comparator is deliberately focused on textual differences.

It does not compare:

images
fonts
colors
graphical layout
visual rendering

It also does not interpret the meaning of a change.

If a value changes from 1200 to 1350, the tool detects the difference, but it does not try to determine whether that change is correct.

The quality of the comparison also depends on the text layer available inside the PDF. A scanned document containing only images cannot be reliably compared without OCR.

Keeping this distinction explicit makes the tool predictable: it does one job and stays focused on it.

Open source

PDF Comparator is available as an open-source project under the MIT License.

The repository contains the Python script, requirements, documentation in English and French, and installation instructions.

Repository

View PDF Comparator on GitHub

Contributions, feedback, issues and improvements are welcome.

Sometimes a useful tool does not need a platform, an account, or another service in the middle.

Two files, one local script, and the differences.

https://palks-studio.com

What if we stopped explaining technology only through text?

Anthony Leignel — Sun, 09 Aug 2026 19:16:07 +0000

I created interactive experiences to show what really happens behind actions that seem simple

A cookie accepted with one click, two systems connected through an API, a task to automate, user authentication, or even a Factur-X invoice.

From the outside, many technical actions look simple.

And that's perfectly normal.

Users see the result, not necessarily everything that needs to happen behind the scenes for that result to work properly.

Of course, these mechanisms can be explained through articles, documentation, or diagrams, but not everyone wants to read several pages to understand a topic, some simply don't have the time, while others understand things better when they can visually follow what is happening.

That's why I started creating a series of interactive experiences.

Understand in just a few clicks

The principle is intentionally simple.

Each experience starts with an action or idea that seems straightforward, then gradually reveals what is actually happening behind the scenes.

Let's take automation.

A request can start with something as simple as:

"Could we automate this task?"

For the person making the request, it really is just one task.

But integrating it properly into a system may require analyzing the existing process, defining business rules, validating data, anticipating errors, securing execution, handling repeated runs, testing different scenarios, and making sure the system remains stable over time.

The experience isn't designed to turn visitors into developers, it simply makes this part of the work visible.

Showing what the interface doesn't show

That's the common thread throughout the collection.

An API can make it look like two systems are simply exchanging data, yet behind a single request there may be authentication, validation, processing, response codes, errors, timeouts, and retries.

A user login may look like nothing more than an email address and a password, while a properly built application needs to perform several checks before granting access.

A Factur-X invoice looks like a PDF, but it also contains structured XML data, and both representations need to tell the same story.

A cookie may seem insignificant, yet it can become the starting point of a much larger chain involving data collection and profiling.

The goal isn't to make these topics seem artificially complicated or alarming, but to show that between a visible action and its result, there is often an entire system the user never sees.

Another way to talk about technology

I like technical articles and documentation, and I publish those too, but I wanted to add a different format.

Something you can explore quickly, without requiring any particular technical background, where a few clicks are enough to understand an idea.

The experiences are therefore intentionally short, visual, and progressive.

Today, the collection covers several areas:

systems and architecture, with from-scratch development, APIs, and automation
security and data, with application authentication, cookies, and personal data
electronic invoicing, with Factur-X

More experiences will be added to the collection, because there are still plenty of technical mechanisms worth making visible this way.

Explore the interactive experiences

If you'd rather experience something than read a long explanation, or if you simply want to discover what happens behind some of the mechanisms we use every day, the full collection is available here:

Explore the interactive experiences

A few clicks are enough, then it's up to you to decide how far you want to follow the journey.

https://palks-studio.com

The Palks Studio Approach

Anthony Leignel — Tue, 04 Aug 2026 14:03:24 +0000

Why Palks Studio exists

Palks Studio was created around a simple observation: many software projects become more complex than they need to be.

New tools are added to solve problems introduced by previous tools. External services become permanent dependencies. Business data is scattered across multiple platforms. Over time, maintenance becomes more expensive than development itself.

I chose a different approach.

The goal is not to build software with the largest possible technology stack. The goal is to build systems that remain understandable, maintainable, and reliable years after they are deployed.

Every project starts with the same question:

How can this problem be solved with the fewest moving parts while remaining robust, secure, and easy to maintain?

Sometimes that means using an existing library. Sometimes it means writing a component from scratch. The decision is driven by long-term stability rather than short-term convenience.

This philosophy shapes every system developed at Palks Studio, from electronic invoicing and business automation to internal tools and backend infrastructures.

Simplicity is an engineering choice

Simple software is often perceived as limited.

In reality, simplicity is usually the result of deliberate engineering decisions.

Every additional service, dependency, framework, or external platform increases the number of components that must be deployed, monitored, updated, secured, and maintained over time.

Keeping an architecture simple is not about avoiding technology. It is about avoiding unnecessary complexity.

At Palks Studio, each component must have a clear purpose. If a feature can be implemented without introducing another layer of abstraction or another external dependency, that option is considered first.

The objective is not to build the smallest application possible. It is to build systems that remain understandable, predictable, and maintainable long after the initial development phase.

A simple architecture is easier to document, easier to audit, easier to debug, and easier to evolve.

Complexity should come from solving business problems, not from the technical stack itself.

Own the infrastructure

Software should not require handing over control of a company's data or infrastructure.

Whenever possible, the systems developed at Palks Studio are deployed directly on the client's own hosting, whether it is a shared server, a VPS, or dedicated infrastructure.

This approach gives the client full ownership of their environment. Their data remains under their control, backups stay on their infrastructure, and the system continues to operate independently of any specific software vendor.

It also simplifies long-term maintenance. There is no proprietary platform to migrate away from, no subscription required to keep the software running, and no dependency on a third-party service that could change its pricing, features, or availability.

The objective is not to avoid cloud services at all costs. It is to ensure that the client remains in control of the software they rely on every day.

Data belongs to the client

Collecting data is easy. Deciding not to collect it requires a different mindset.

At Palks Studio, systems are designed to keep only the information that is necessary for their intended purpose. If a piece of data has no operational value, it should not be stored.

The same principle applies to the public website. It operates without advertising trackers, analytics scripts, or unnecessary cookies. Visitors are not profiled, and browsing does not generate data that serves no purpose.

Keeping less data has practical benefits. It reduces storage requirements, simplifies compliance with privacy regulations, limits the impact of a potential data breach, and makes systems easier to understand and maintain.

Data should help users achieve their goals. It should not become a product in itself.

This principle guides every project developed at Palks Studio.

Security starts with architecture

Security is often associated with encryption, firewalls, or authentication.

These are important, but they are only part of the picture.

A system also becomes more secure by reducing what it exposes.

Fewer external services mean fewer communication channels.

Fewer dependencies mean fewer components that require security updates.

Fewer stored data mean less information that could be compromised.

Whenever possible, systems are designed with a clear separation between public and private components. Configuration files, business logic, and sensitive data remain outside the public web root, while only the elements intended to be accessed by users are exposed.

The objective is not to eliminate every risk. It is to reduce the attack surface before the software is even deployed.

Good security is not only something added to a system.

It is something built into its architecture from the beginning.

Business rules before automation

Automation is often presented as the solution.

In reality, it only amplifies the quality of the process it executes.

Automating a poorly designed workflow does not make it better. It simply allows the same mistakes to happen faster and more consistently.

Before introducing automation, the business rules must be clearly defined:

What should happen?
Under which conditions?
What data is required?
What makes a process valid?

Only when these questions have clear answers does automation become valuable.

This principle applies to every project developed at Palks Studio. Whether generating a Factur-X invoice, processing job applications, or orchestrating a business workflow, the objective is always the same: understand the business logic first, then automate its execution.

Automation should execute decisions.

It should not replace them.

Systems instead of tools

A tool solves a task.

A system supports a workflow.

This distinction shapes every project developed at Palks Studio.

A billing system is more than invoice generation. It also manages quotations, signatures, payments, structured archives, compliance rules, and future interoperability.

A recruitment system is more than a form. It evaluates candidates, applies business rules, ranks profiles, manages campaigns, and keeps the recruitment process consistent.

An automation system is more than a script. It validates data, executes predefined workflows, handles errors, produces traceable outputs, and remains predictable over time.

The objective is never to automate a single action in isolation.

It is to build systems that remain coherent as they grow.

Good software is not defined by the number of features it contains.

It is defined by the reliability of the workflow it supports.

A philosophy that guides every project

Technologies evolve.

Libraries are replaced.

Standards change.

Business requirements grow.

The principles behind a well-designed system should remain the same.

Build only what is necessary.

Keep the architecture understandable.

Reduce unnecessary dependencies.

Protect the client's data.

Design business rules before automating them.

Create systems that can still be understood, maintained, and trusted years after they are deployed.

Every project developed at Palks Studio follows these principles.

They are not constraints.

They are the foundation.

https://palks-studio.com

I Built a Local VS Code Environment That Puts Me Back in Control

Anthony Leignel — Wed, 01 Jul 2026 17:27:54 +0000

Why I Built It

For years, I kept adding new tools to my development environment because every extension, formatter, or utility promised to make development faster. At first it worked, but over time my workflow became harder to understand. Files were modified automatically, formatting changed from one project to another, and some actions happened in the background without me even noticing.

The problem wasn't Visual Studio Code, and it wasn't the extensions themselves. The real problem was that I had gradually stopped controlling my own development environment.

Instead of installing even more tools, I started removing them. I replaced hidden automation with explicit actions and built a lightweight local environment around a simple principle:

Nothing should modify my code unless I decide it.

Over time, this approach evolved into what is now my VS Code Environment Pack. Rather than trying to automate everything, it provides a collection of local tools that help me create projects, maintain codebases, generate documentation, keep timestamped backups, and automate repetitive tasks while keeping every action predictable and under my control.

Every Project Starts the Same Way

One of the first repetitive tasks in any project has nothing to do with writing code.

Creating folders.

Creating empty files.

Reproducing the same directory structure again and again.

It doesn't take long, but after dozens of projects it becomes unnecessary work.

Instead of creating everything manually, I describe the project structure once in a simple structure.txt file. Running a single task generates the complete hierarchy, including every folder and file exactly where it belongs.

my_project

    README.md

    app

        app.py

    static

        css

            style.css

The goal isn't to generate code.

It's to start every project from a clean, consistent structure, so I can focus on solving the actual problem instead of rebuilding the same foundation every time.

Documentation Should Never Be Manual

Understanding a project often starts with a simple question:

How is it organized?

When a codebase grows, answering that question manually becomes surprisingly time-consuming. Taking screenshots, writing folder structures, or listing files by hand quickly becomes outdated.

That's why I built tree.py.

With a single task, it scans the entire project and generates a PROJECT_TREE.txt file representing the complete directory structure.

my_project/
├── app
│   ├── app.py
│   └── controllers
├── static
│   ├── css
│   └── js
├── README.md
└── requirements.txt

I use it to document projects, share their architecture, review existing codebases, and quickly understand how a project is organized.

Like every other tool in this environment, it performs one task, does it locally, and produces a result that is easy to read, reuse, and version.

Every Change Is Intentional

One of the principles behind this environment is that no script should modify more files than necessary.

That's why most maintenance tools can run in three different modes.

Sometimes I want to clean an entire project before committing it.

Sometimes I only want to work on the file I'm editing.

And sometimes I need to target a small selection of files without touching anything else.

Instead of forcing a single workflow, the environment adapts to the situation.

The same approach applies to cleaning whitespace, converting line endings, and other maintenance tasks. Every operation can be executed on the whole project, the active file, or a custom selection.

Nothing runs automatically in the background.

Nothing changes unless I ask for it.

That level of control makes maintenance safer, especially on large projects where a single unintended modification can affect hundreds of files.

Every Save Creates a Safety Net

Making changes is part of development.

Deleting the wrong block, trying a different implementation, or restructuring a file happens every day. Most of the time, version control is enough. Sometimes, it isn't.

I wanted something much simpler.

Every time I save a file, a timestamped copy is created automatically inside a local backup directory. Nothing is uploaded, nothing is synchronized, and nothing depends on an external extension or service.

If I realize a mistake a few minutes later, I don't need to search through Git commits or recover a deleted file. The previous version is already there.

More importantly, this changes the way I work.

I can experiment more freely because I know every saved version still exists. Refactoring becomes less stressful, trying a new approach becomes easier, and recovering from a mistake takes seconds instead of minutes.

The backup system isn't just about protecting files.

It's about giving me the confidence to change them.

Small Tools, One Responsibility

One design decision guided the entire project: every tool should solve one problem, and solve it well.

Instead of building one large application responsible for formatting, backups, project generation, documentation, and file maintenance, I chose to keep every feature independent.

create.py creates projects.

tree.py documents them.

clean.py removes unnecessary whitespace.

space.py reports formatting issues without modifying anything.

convert.py normalizes line endings.

backup.py keeps timestamped copies of every saved file.

Each tool can evolve independently, remain easy to understand, and be reused in other projects without bringing along features that aren't needed.

The result isn't just easier to maintain.

It's easier to trust.

When a tool has one responsibility, you always know why you're running it and exactly what it will do.

Conclusion

This project didn't start as a VS Code pack.

It started with a simple question:

How can I build an environment that stays predictable, even as my projects become larger and more complex?

Over time, the answer became a collection of small local tools designed to solve everyday problems without introducing unnecessary complexity.

Creating projects.

Documenting architectures.

Maintaining codebases.

Keeping local backups.

Cleaning and formatting files.

Every tool has a single responsibility, every action is explicit, and every modification remains under my control.

Today, this environment is part of every project I build.

Not because it automates everything, but because it automates the right things while letting me decide when and how they happen.

For me, that's what a good development environment should do.

It shouldn't write code for the developer.

It should help the developer write better code with confidence.

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

I Built a Local Data Collection System in Python

Anthony Leignel — Thu, 04 Jun 2026 17:13:36 +0000

Why I Built It

Most data collection and lead generation tools are delivered as SaaS products.

You create an account, subscribe, send your data to a third-party platform and keep paying every month to continue using the tool.

I wanted a different approach.

I built a fully local data collection system that runs on the user's machine, without subscriptions, without paid APIs and without relying on external platforms.

The goal was simple:

Create searches
Collect data from multiple sources
Clean and validate the results
Export usable data
Keep everything under the user's control

What the System Does

The application allows users to create and manage searches from a web interface.

For each search, users can define:

A search name
A keyword
A city
A country
The search engines to use

The system currently supports:

DuckDuckGo
Bing
Qwant

Once a search is executed, the collection engine starts gathering information from the selected sources.

Data Processing Pipeline

The system follows a structured workflow.

Load Configuration
↓
Initialize Environment
↓
Load Searches
↓
Run Collectors
↓
Clean Data
↓
Normalize Data
↓
Validate Records
↓
Remove Duplicates
↓
Generate Exports
↓
Save Results

Each component has a single responsibility.

Collectors collect data.

Processors clean and validate it.

Exporters generate output files.

The main engine orchestrates the workflow.

Extracting Business Information

The system doesn't stop at search engine results.

When a website is discovered, the application can visit the site and extract useful information such as:

Website URL
Email addresses
Phone numbers
Company name
Location information

The collected data is then normalized and validated before being added to the final dataset.

Managing Contacted Leads

One feature I wanted from the beginning was lead tracking.

Users can mark prospects as contacted directly from the interface.

The information is stored locally and remains available after closing the application.

This makes it easy to distinguish:

New prospects
Already contacted prospects

without relying on an external CRM.

Exporting Data

Once processing is complete, results can be exported as:

CSV
JSON

The exported files are ready to be imported into other systems or used for further analysis.

Local First

One of the main design goals was independence.

The system runs locally.

There is:

No SaaS
No subscription
No third-party account
No paid API dependency

The user owns the software and the collected data.

Technical Stack

The project is built with:

Python
Flask
Playwright
BeautifulSoup
Requests

The interface is served locally through Flask and can be accessed from a browser.

Final Thoughts

This project started as a simple data collection tool and gradually evolved into a complete workflow capable of collecting, processing and exporting structured business data.

Building it locally introduced some interesting challenges around browser automation, data normalization, validation and architecture design.

The result is a modular system that can be extended with new collectors, processors and export formats without changing the overall architecture.

For me, the most important aspect remains simple:

The software belongs to the user and the data never has to leave the machine.

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

I Built a Full Recruitment System in PHP: No Database, No SaaS, No Subscription

Anthony Leignel — Fri, 15 May 2026 19:53:59 +0000

Automatic candidate scoring, recruiter dashboard, multi-campaign management. Deployed on any standard Apache hosting.

After building a complete invoicing system the same way, I applied the same philosophy to recruitment: no SaaS dependency, no monthly subscription, no data leaving the client's server.

The result is CANDIDATE_SYSTEM, a self-hosted recruitment engine that automatically scores applicants against a job profile, ranks them by matching score, and lets the recruiter focus on the top profiles instead of reading through dozens of CVs.

The Problem With Existing Tools

Most recruitment platforms follow the same model: you pay monthly, your data sits on their servers, and the day you stop paying, everything disappears.

For small companies, DSIs, and independent recruiters, this makes no sense. They don't need a 300€/month SaaS. They need a simple, reliable tool that works on their own hosting.

How It Works

The system is split into two parts:

Public: the application form (/candidat/)
Private: configuration, scoring engine, candidate data (outside the webroot)

When a candidate submits the form, the scoring engine calculates a final score based on three nested levels:

contribution = scores[answer] × (weight / 100) × (global_weight / 100)

Level 1: global_weight, how much a section counts in the final score.

Level 2: weight, how much a question counts within its section.

Level 3: scores, the raw value assigned to each possible answer (0 to 100).

Every candidate gets a score on submission. The dashboard displays them ranked from highest to lowest.

The Scoring Engine

The scoring logic lives in a single $coring class. It reads the campaign configuration files, questions with their weights and scores, and the job profile, then runs the calculation across all sections.

public function calculate(array $reponses): array
{
    foreach ($this->questions as $question) {
        $score_brut   = $this->getScoreBrut($question, $reponses[$question['id']]);
        $contribution = $score_brut * ($question['weight'] / 100);
        $detail[$question['section']]['score_section'] += $contribution;
    }

    foreach ($detail as $section_id => &$section) {
        $section['contribution'] = $section['score_section'] * ($section['global_weight'] / 100);
        $score_final += $section['contribution'];
    }

    // Apply penalties
    foreach ($this->profil['malus'] ?? [] as $question_id => $penalties) {
        if (isset($penalties[$reponses[$question_id]])) {
            $malus += $penalties[$reponses[$question_id]];
        }
    }

    return ['score_final' => round(max(0, $score_final + $malus), 1), ...];
}

The tech stack question (checkbox type) is scored differently, each selected technology is matched against the scores defined in the question itself. No hardcoded list, fully configurable from the admin interface.

Multi-Campaign Architecture

Each campaign is completely independent: its own questions, its own job profile, its own candidate data.

campaigns/
└── [slug]/
    ├── config/          → questions, scores, job profile
    └── data/            → applications, uploads, lock file

Creating a new campaign from the dashboard copies the templates, generates the folder structure, and redirects immediately to the new campaign. One click, ready to use.

A campaign.lock file controls whether the form is open or closed. The recruiter can close a campaign (which purges all candidate data and sends a closure email to every applicant), then reopen it later from the dashboard.

The Admin Interface

The recruiter configures everything from the admin panel, no file editing required:

Job profile: position title, mission type, location, salary range
Questions: edit labels, answers, scores, section weights; add or delete questions
Section weights: real-time total indicator (must reach 100%)
Penalty rules: attach negative scores to specific answers on specific questions
Settings: sender name, email, site URL, dashboard password

The section weight total updates in real time as you type. If it doesn't add up to 100%, the indicator turns red.

No Database: Just JSON Files

Every application is stored as a flat JSON file:

{
    "id": "20260514_143000_abc123",
    "date": "2026-05-14 14:30:00",
    "score_final": 74.5,
    "score_label": "Good fit",
    "score_detail": {
        "terrain": { "score_section": 68.0, "contribution": 40.8 },
        "classic": { "score_section": 75.0, "contribution": 15.0 }
    },
    "reponses": { ... },
    "trigger_fields": { ... }
}

No ORM, no migrations, no connection pooling. The dashboard loads all JSON files from the applications/ folder, sorts them by score_final, and renders the list.

It's fast enough for the volumes this tool is designed for, typically 20 to 200 applications per campaign.

Security

A few things worth noting:

CSRF token on the application form, generated per session and validated on submission
Strict public/private separation, no configuration file is accessible via the web
Duplicate prevention, one email per campaign, checked on every submission
Upload validation, PDF only, 5 MB max, with extension and MIME type verified
HTTP security headers on every page (X-Frame-Options, X-Content-Type-Options, Referrer-Policy)
Session required for the dashboard, exports, application viewing, and campaign closure

Conditional Form Fields

Some questions trigger additional fields depending on the answer. For example, answering "Yes" to "Do you have a portfolio?" reveals a required URL field. Answering "Yes" to "Any certifications?" triggers a PDF upload.

The trigger configuration lives in the questions config file:

{
    "id": "portfolio",
    "trigger": {
        "value": "Oui",
        "field_id": "portfolio_url",
        "field_type": "url",
        "field_label": "Portfolio URL",
        "required": true
    }
}

On the frontend, a small JS handler watches radio inputs and toggles the conditional field visibility. On the backend, handler.php only validates the conditional field if the triggering answer was given.

What Gets Delivered

When deployed for a client:

Full system installed on their hosting
First campaign configured with their job profile
Admin interface ready to use
Technical documentation + user guide
Color customization included

No recurring cost. No dependency on external infrastructure. One flat fee.

Stack

PHP 8.x: no framework, no Composer
Apache + .htaccess: URL rewriting, security headers, directory protection
Vanilla JS: form validation, clipboard API, accordion UI
JSON flat files, zero database

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

I built a fully automated Factur-X EN16931 batch pipeline in PHP: no SaaS, no agent, just cron and strict business logic

Anthony Leignel — Wed, 13 May 2026 14:04:09 +0000

How a Monthly Cron Cycle Replaces an Entire Invoicing Platform

The goal wasn't to automate individual tasks.

It was to automate an entire monthly invoicing cycle.

From CSV import to Factur-X generation, payment tracking, secure delivery, and revenue reporting, every step runs through the same deterministic pipeline.

No SaaS.

No database.

No background service.

Just PHP, cron, and business rules.

Why I built it this way

The requirement was simple on paper: take client data every month, generate Factur-X EN16931 compliant invoices, track payments, and deliver everything securely.

The constraint was harder: no SaaS dependency, no shared infrastructure, no implicit processing. Every step had to be explicit, traceable, and stoppable.

That constraint shaped every architectural decision.

The monthly cycle

Onboarding

Before the first invoice is ever generated, every client is initialized automatically from a form submission. A unique identifier is generated, configuration files are created, archiving folders are structured, and payment tracking is prepared. No manual intervention required. The system is ready to process.

D1 to D7: CSV deposit and batch generation

Each client deposits their billing data via a secured form. The system validates structure and formats strictly, with no implicit tolerance and no silent correction. A malformed field stops the entire client batch, isolates it, and triggers an automatic notification for correction before reprocessing.

If valid, batch generation runs daily via cron. Invoice composition is driven entirely by business rules, including rates, VAT zones, service periods, and multi-line and multi-month billing. The output is a Factur-X EN16931-compliant PDF/A-3 document with embedded XML, making it both human-readable and machine-readable.

D8: B2B invoice and automatic pricing tier

On day 8, the system detects the volume of invoices generated during the period and derives the applicable pricing tier automatically. The monthly B2B invoice is then generated and sent by email with the PDF attached. No manual input. The cron runs, the logic decides.

D13 to D14: The only manual step

This is the single human touchpoint in the entire cycle: recording received bank transfers. Everything else is automated. This separation is intentional, because payment validation is a business decision, not a technical one.

D15: Balance recalculation and payment control

Two operations run on day 15. First, client balances are recalculated from recorded payments. Unpaid clients are automatically deactivated, blocking any further send operations until the situation is resolved. Second, paid receipts are sent to clients with confirmed payment status via cron.

D16: Secured delivery

The monthly ZIP is sent once. A deduplication guard ensures nothing can be sent twice, regardless of cron retries or manual triggers. Delivery uses a temporary token, making the file accessible only through a time-limited secured link. The archive is retained independently.

What makes it deterministic

Every processing decision is explicit. There is no magic, no silent fallback, no implicit correction.

If a CSV is invalid the client batch stops.

If a client is unpaid sends are blocked.

If a ZIP was already sent the guard refuses the duplicate.

Every operation is timestamped in technical logs. Client state is controlled via explicit flags. The revenue journal is updated on every confirmed payment.

The system is designed to be readable by anyone who picks it up. Not clever. Predictable.

Stack

PHP 8: backend logic and cron execution
mPDF: PDF generation
factur-x (Python, Akretion): Factur-X XML injection and PDF/A-3 conversion
Flat-file storage: contracts, invoices, counters, logs, revenues
No database. No SaaS. No external API dependency

What I Learned

Building this pipeline wasn't about automating invoice generation.

It was about designing a system where every execution produces the same predictable result.

Once the business rules were defined, cron simply became the engine that executes them.

Automation wasn't the goal.

Reliability was.

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

How I Integrated Factur-X EN16931 into an Existing PHP Billing System

Anthony Leignel — Mon, 11 May 2026 10:17:35 +0000

Integrating Factur-X into an Existing PHP Application

As the French e-invoicing reform (RFE) moved closer to implementation, I needed to make my billing system compliant without replacing the existing application. Rather than switching to a SaaS platform or adopting an ERP, I chose to integrate the Factur-X standard directly into an existing PHP application running on a standard Apache server.

This article explains the architecture I built, what the standard actually requires, and the technical challenges I encountered along the way.

What is Factur-X?

Factur-X is a Franco-German standard for structured electronic invoicing that combines two elements into a single document:

A human-readable PDF/A-3 invoice
An embedded XML document compliant with the EN16931 European standard

Both are required. The PDF is intended for people, while the XML is intended for accounting software and automated processing. Together, they form a single electronic invoice.

Although Factur-X originated in France and Germany, it aligns with the European EN16931 standard and is part of the broader transition toward mandatory e-invoicing across Europe.

The VAT Legal Mentions, the Part Most Developers Miss

Generating a valid Factur-X file is only part of the job. The invoice itself must also include the correct VAT legal mention according to the client's location. Getting this wrong isn't a formatting mistake, it's a fiscal compliance issue.

When the issuer is based in France, there are three possible situations.

French client

The issuer is a micro-enterprise or is not subject to VAT. The invoice must include the following legal mention:

TVA non applicable, art. 293B du CGI

No VAT is applied, no VAT column appears on the invoice, and the legal mention is mandatory.

EU client (B2B with a VAT number)

The transaction falls under the reverse charge mechanism, meaning the customer declares the VAT in their own country. The invoice must include:

Autoliquidation – TVA due par le preneur, art. 283-2 du CGI

VAT is set to 0% and the legal mention replaces the usual VAT information.

Non-EU client

The service is exported outside the European Union. VAT exemption applies under the French tax code, and the invoice must include:

Exonération de TVA – art. 262 I du CGI

Again, VAT is set to 0%, but the legal mention remains mandatory.

These aren't optional notes added for convenience. They explain why VAT is absent or transferred, and using the wrong one can become a compliance issue during a tax audit.

In my billing system, the correct legal mention is selected automatically from the client's ISO country code and VAT number. The developer doesn't choose it manually. The business rules do.

The Technical Chain: How Factur-X Is Actually Generated

Generating a Factur-X invoice is split into two distinct phases, each handled by a dedicated component. This separation is intentional because XML generation and PDF/A-3 conversion solve different problems and have different technical requirements.

Phase 1: Building the XML

The first step is handled by a PHP component responsible for generating the EN16931-compliant XML document.

It reads the invoice data, including issuer and client details, service lines, VAT amounts, totals, and payment terms, then maps every value to its corresponding EN16931 business term. The generated document follows the Factur-X Comfort profile, covering the information required for standard B2B invoicing.

Several business rules must be respected during this phase:

Amounts use strict decimal formatting with no implicit rounding
VAT is aggregated by rate rather than by invoice line
Seller and buyer identifiers (SIREN, SIRET, VAT number) are placed in the appropriate XML elements according to the client's location
The VAT legal mention determined earlier is written as structured XML data, not only as visible text in the PDF

The generated XML is stored temporarily before the second phase begins.

Phase 2: Injecting the XML into the PDF

The second step is handled by a Python component using the Factur-X library developed by Akretion, one of the organizations behind the standard.

Its role is straightforward:

Read the PDF generated by the PHP billing engine using mPDF
Embed the EN16931 XML document
Convert the final document to the PDF/A-3b format required by Factur-X

I chose Python for this stage because the Factur-X library provides reliable PDF/A-3 conversion and XML embedding without introducing heavy PHP dependencies. It also validates the generated XML against the EN16931 schemas before embedding it, providing an additional compliance check.

The result is a single PDF/A-3 document containing the embedded XML, fully compliant with the Factur-X EN16931 Comfort profile.

Temporary Files

The XML only exists for as long as it is needed.

It is written to a dedicated temporary directory, embedded into the PDF during the second phase, then deleted automatically once the final document has been generated. Only the completed Factur-X invoice is retained.

What This Architecture Delivers

The result of this pipeline is a single document that is both human-readable and machine-readable: a Factur-X EN16931-compliant PDF/A-3 containing its embedded XML, ready for transmission to a French Partner Dematerialization Platform (PDP) or direct exchange with a client.

Beyond compliance, this architecture provides several practical advantages.

Self-Hosted by Design

The entire generation pipeline runs on the same server as the billing system. No external API is called during invoice generation, and no financial data leaves the infrastructure.

For organizations that require full control over their accounting data, this removes the dependency on third-party cloud services during document generation.

Independent from an ERP

The system doesn't rely on an ERP or existing accounting software.

Invoices are generated directly from the billing workflow, using the client information, service lines, VAT rules, and payment terms already managed by the application.

This makes the solution suitable for businesses that need Factur-X compliance without replacing their existing processes.

Compliance Built into the Workflow

Compliance isn't added at the end of the process.

VAT rates, legal mentions, and business rules are determined before the document is generated, then represented consistently in both the visible PDF and the embedded XML.

The result isn't simply a document that looks compliant.

It's a workflow designed to produce compliant invoices by construction.

Conclusion

Integrating Factur-X into an existing billing system isn't only about generating XML or converting a PDF to PDF/A-3.

The real challenge is translating business rules into structured data before the invoice is created.

The architecture described here, PHP for XML generation and Python for PDF/A-3 conversion and XML embedding, has allowed me to integrate Factur-X into an existing application without introducing an ERP, a SaaS platform, or unnecessary complexity.

If you're working on a similar integration, I hope this overview helps clarify where the real challenges lie.

Once the business rules are modeled correctly, generating a compliant Factur-X invoice becomes the easiest part of the process.

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

Dependency as an Engineering Trade-Off

Anthony Leignel — Sun, 10 May 2026 14:49:48 +0000

Stability, control and long-term maintainability in backend systems

Dependencies are everywhere in modern software development.

Frameworks, libraries, external services, and specialized tools help accelerate development and avoid reinventing existing solutions.

In many situations, this is a reasonable choice.

A dependency can reduce development time, provide proven functionality, and simplify complex implementations.

However, every dependency also introduces a trade-off that is often invisible at first: part of the system’s behavior is no longer fully controlled by the people building it.

Solving problems today, creating complexity tomorrow

Adding a dependency usually solves an immediate problem.

A feature is implemented faster, with less effort, and the system moves forward quickly.

Over time, however, dependencies evolve:

breaking changes between versions
behavioral changes
reduced maintenance or abandonment
new technical constraints

The system may continue to function, but its stability increasingly depends on external factors.

Complexity rarely appears immediately.

It accumulates gradually as the system evolves.

When behavior escapes the system

The more layers a system relies on, the harder it becomes to explain why it behaves in a certain way.

An issue may originate from:

application code
an intermediate library
a version change
or an external service

A backend system may suddenly behave differently after what appears to be a minor update:

a dependency changes an internal behavior, an external API modifies a response format, or a framework update introduces a new constraint.

Nothing in the business logic was intentionally changed, yet the system itself no longer behaves the same way.

This diffusion of responsibility increases uncertainty.

Understanding a problem often requires understanding multiple systems at once.

At that point, the difficulty is no longer purely technical.

It becomes structural.

Reducing dependencies means reducing uncertainty

Reducing dependencies does not mean rejecting existing tools.

It means deciding what should truly belong to the system.

Some functionalities are central enough to justify a simple, controlled implementation. Others can remain external without significant impact.

The goal is not to minimize dependencies at all costs, but to limit those that directly influence core logic or critical system behavior.

The fewer external elements a system depends on, the more predictable its behavior becomes.

Stability as a consequence of control

The systems that are easiest to maintain are not necessarily those using the fewest tools.

They are often the ones where dependencies are clearly identified and limited to areas where they provide real value.

When the essential parts of a system remain under control, external changes become less risky.

Stability does not come from avoiding change, but from understanding what actually changes.

Balance rather than rejection

Dependencies are an integral part of modern development.

They allow teams to build faster and benefit from shared knowledge.

But every dependency shifts part of the control outside the system itself.

Understanding this trade-off leads to better decisions: accepting dependencies when they genuinely simplify the problem, and reducing them when they introduce more uncertainty than value.

Over time, these often invisible decisions determine whether a system remains understandable or gradually becomes difficult to evolve.

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

AI Agents Writing All Your Code: Comfort or Loss of Control?

Anthony Leignel — Fri, 24 Apr 2026 15:10:07 +0000

The new reflex: delegate everything

Over the past few months, we’ve seen the rise of AI agents capable of:

generating full codebases
modifying existing projects
automating complex tasks
making technical decisions

The reflex is simple:

“I’ll just let the AI handle it.”

And it works.

At least, on the surface.

The problem: we no longer know what we’re running

When an agent:

writes code
modifies files
restructures a project

who actually understands what’s going on?

In many cases:

the code is accepted without review
the logic is not fully understood
entire parts become opaque

We gain speed.

But we lose something fundamental:

understanding.

A system that works… until it breaks

It’s the same pattern we’ve seen before:

it works
we stack layers
we trust it
then one day… it breaks

And when it does:

no one knows where to look
no one understands the full logic
the system becomes hard to fix

The question no one is asking

Today, the focus is on performance, productivity, speed.

But very few people ask the real question:

what happens when we no longer control what we execute?

Because tomorrow, the issue might not be:

a bug
a mistake
a bad implementation

But something deeper:

total dependence on a system we don’t understand

What if we start hearing about compromised agents?

Today, it may sound exaggerated.

But we’ve already seen:

compromised dependencies
libraries injecting malicious code
popular tools becoming attack vectors

So the question is simple:

if an agent controls part of your code… what happens if it’s compromised?

And more importantly:

who is able to detect it?

The real issue isn’t AI

AI isn’t the problem.

It’s a powerful tool.

Useful.

Sometimes impressive.

The problem is how we use it.

Assistant vs pilot

There’s a huge difference between:

using AI as an assistant
letting AI take control

In one case:

you gain speed
you keep control

In the other:

you accelerate
but you lose understanding

Taking back control

Using AI agents isn’t a bad thing.

But a few simple principles make all the difference:

understand what is generated
limit automated layers
avoid delegating critical parts
keep logic simple and readable

Conclusion

Technology is moving fast. Very fast.

And AI agents will take more and more space.

But as automation increases, control can decrease.

And in technical systems, speed is not what makes them reliable.

Understanding is.

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

DEV Community: Anthony Leignel

How Many Obsolete Dependencies Are You Using Without Knowing It? An Open Source Checker

Security also starts with what we install

An alert before a vulnerability becomes your problem

A tool that does not make decisions for you

Deprecated does not mean vulnerable

Why is it open source?

You do not need to be a developer to understand the result

A database designed to evolve

A few seconds to look at what we are using

Comparing PDF and XML Data Locally with Python, Open Source

A lightweight open source tool for detecting differences between two representations of the same document

The problem

A deliberately simple approach

Compare Two PDF Files Locally with Python, Open Source

A lightweight open-source tool for detecting textual differences between PDFs

How it works

Running it

Local by design

What it can be useful for

What it does not do

Open source

Repository

What if we stopped explaining technology only through text?

I created interactive experiences to show what really happens behind actions that seem simple

Understand in just a few clicks

Showing what the interface doesn't show

Another way to talk about technology

Explore the interactive experiences

The Palks Studio Approach

Why Palks Studio exists

Links

Simplicity is an engineering choice

Own the infrastructure

Data belongs to the client

Security starts with architecture

Business rules before automation

Systems instead of tools

A philosophy that guides every project

I Built a Local VS Code Environment That Puts Me Back in Control

Why I Built It

Links

Every Project Starts the Same Way

Documentation Should Never Be Manual

Every Change Is Intentional

Every Save Creates a Safety Net

Small Tools, One Responsibility

Conclusion

Go Further

I Built a Local Data Collection System in Python

Why I Built It

Links

What the System Does

Data Processing Pipeline

Extracting Business Information

Managing Contacted Leads

Exporting Data

Local First

Technical Stack

Final Thoughts

Go Further

I Built a Full Recruitment System in PHP: No Database, No SaaS, No Subscription

Automatic candidate scoring, recruiter dashboard, multi-campaign management. Deployed on any standard Apache hosting.

Links

The Problem With Existing Tools

How It Works

The Scoring Engine

Multi-Campaign Architecture

The Admin Interface

No Database: Just JSON Files

Security

Conditional Form Fields

What Gets Delivered

Stack

Go Further

I built a fully automated Factur-X EN16931 batch pipeline in PHP: no SaaS, no agent, just cron and strict business logic

How a Monthly Cron Cycle Replaces an Entire Invoicing Platform

Links

Why I built it this way

The monthly cycle