Drones: when the design cycle drops from ten years to ten months, traceability becomes the limiting factor

The figures from the first half of 2026 tell the story of an unprecedented industrial transformation in defense aerospace. The DGA (the French defense procurement agency) has ordered 5,000 DELCO drones for the Army, with delivery rates that would have seemed unrealistic three years ago. Eurenco has built a production capacity of 10,000 to 15,000 warheads per month, adaptable to any type of drone. At Eurosatory, the aisles dedicated to drones, remotely operated munitions and counter-drone systems eclipsed the traditional platforms, and the lessons learned from Ukraine forced an obvious conclusion on every European general staff: mass, iteration speed and unit cost have become parameters of military superiority on the same footing as performance.

This conclusion hits the industrial model of defense aerospace head-on. A combat aircraft program is designed over ten or fifteen years, with requirements frozen at milestones spaced far apart and documentation that follows the stately rhythm of program reviews. A modern tactical drone is designed in ten months, modified every month on the basis of field feedback, and becomes obsolete within two years if its manufacturer stops iterating. Between these two worlds, the ratio of speeds is ten to fifty.

The question this article wants to raise is simple: in this new regime, what becomes of the engineering rigor that underpins the credibility of the defense industry, the traceability of requirements, configuration management, the airworthiness and safety demonstration? Our answer: it can only survive if it changes its medium. At a high iteration pace, document-based traceability dies; structured traceability becomes the factor that separates the manufacturers who scale from those who collapse under their own speed.

The drone paradox: iterate like a startup, prove like an aircraft manufacturer

The defense drone manufacturer lives in a permanent paradox. On one side, its market demands rapid iteration: countermeasures evolve in weeks, operational feedback forces changes to payload, data link and navigation, and the state customer itself pushes to integrate lessons from the field without delay. The winning engineering culture is that of software: short cycles, frequent releases, continuous improvement.

On the other side, that same manufacturer sells to state customers who rightly demand the full apparatus of proof of defense aerospace: compliance with the DGA's contractual requirements, qualification of changes, airworthiness for the segments subject to it, munitions safety for armed systems, export control (each variant delivered to each customer must be exactly the one authorized), and complete traceability of delivered configurations, unit by unit.

In short: iterate like a software startup, prove like an aircraft manufacturer. Neither of the two existing industrial cultures knows how to do both. The traditional aircraft manufacturer knows how to prove but not how to iterate fast; the startup knows how to iterate but discovers the scale of the proof requirement along the way, often at the worst possible moment, the transition to series production or the first export contract.

Where the document-based model breaks

Let us look mechanically at what happens when the classic document-based methods are applied at a monthly iteration rhythm.

A tactical drone represents, as an order of magnitude, a few hundred to a few thousand requirements (contractual, regulatory, derived), a bill of materials (BOM) of a few hundred references, around ten versioned embedded software packages, and a justification file that links it all together. With each monthly change, you have to: identify the affected requirements; update the relevant specifications; determine the tests to rerun, on the ground and in flight; update the qualification file and, where applicable, the airworthiness file; revise the production and maintenance documentation; and trace which units, delivered or in progress, carry which definition.

With Word documents, Excel matrices and a document management system, each monthly cycle generates dozens of cross-referenced updates whose completeness rests on human vigilance. By the third cycle, the first inconsistencies appear. By the tenth, the justification file no longer describes the real product, and the gap is paid for at the most costly moment: an official test campaign, a DGA audit, an export license request, or worse, a post-incident investigation.

The symptoms are identifiable and we find them at most of the sector's hypergrowth players: senior engineers turned into archivists of consistency, configuration freezes that grow ever longer before each delivery, an inability to answer quickly the question "which delivered units are affected by this defect?", and audit preparation that mobilizes the entire company for weeks.

It has to be said plainly: this is not a discipline problem. It is a problem of information physics. The document-based model has a maximum throughput of absorbable changes, and the iteration pace of the modern drone exceeds that throughput by an order of magnitude.

The architecture that holds the pace

The solution is neither to slow down iteration, commercially suicidal, nor to hire ever more writers, economically absurd. It consists of changing the structure: making engineering live in a graph-based repository whose documents are nothing more than generated views.

In this model, the requirements, functions, hardware components, software versions, tests and their results, configurations and series units exist as connected objects. Three capabilities follow from this, which respond exactly to the three breaking points of the document-based model.

First capability: impact analysis in minutes. A proposed change (new data-link module, battery change, navigation software update) translates into a graph traversal that identifies the affected requirements, the tests to rerun, the documents to regenerate and the units concerned. The change review no longer consists of reconstructing the impact, but of validating it.

Second capability: incremental qualification. Because each piece of proof is attached to the exact versions it covers, the qualification gap between definition N and definition N+1 is computable: what remains covered, what must be rerun. This is the condition for qualification to keep up with the monthly pace without starting over from scratch, and it is precisely what the authorities and the DGA expect from mature configuration management.

Third capability: native per-unit traceability. Each serial number is linked to its exact configuration, itself linked to the applicable proof and the corresponding export authorizations. The question "what exactly is in what was delivered to customer X in March?" gets an exact answer in seconds, which transforms the management of defects, retrofits and export control.

This is the architecture that Koddex offers to players in the sector: a graph-based Engineering OS, designed for regulated European industries, that centralizes requirements, bills of materials, impact analyses and certification traceability, and that absorbs the iteration rates that the document-based model cannot follow.

The strategic stake: traceable speed as a competitive advantage

Let us raise the perspective. The European defense drone market is in the process of structuring itself, and the technical barriers to entry (designing a drone that flies) are lowering while the industrial barriers (delivering thousands of them, compliant, to states) are rising. Over the next five years, framework orders will go to the manufacturers able to demonstrate three things simultaneously: product performance, ramp-up capability, and proven control of their definitions and configurations.

State buyers have learned from recent difficulties: they now audit the configuration management of candidates before awarding the major contracts, because they know that a supplier unable to trace its changes will become a problem of operational availability and safety. Structured traceability ceases to be a compliance cost and becomes a selection criterion, on the same level as unit price.

There is more. Iteration speed itself, the sector's number-one commercial argument, depends directly on the quality of the repository. A manufacturer whose impact analysis takes three weeks iterates four times slower than a manufacturer where it takes one hour, with equal teams. In other words: in this market, the data structure is a speed multiplier, and speed is the product.

Conclusion: rigor at the speed of war

The drone has imposed a new temporal regime on the European defense industry, and this regime is here to stay: today's 5,000 DELCO foreshadow tomorrow's tens of thousands of units, with definitions that will evolve continuously. In this regime, the classic opposition between speed and rigor is a false dilemma inherited from obsolete tooling. Document-based rigor cannot hold the speed; structured rigor multiplies it.

The manufacturers who build their engineering on a traceable repository starting now will iterate faster than their competitors while proving better than them. The others will discover that at the speed of war, it is the data that breaks first.

Sources

- La DGA commande 5 000 drones du combattant Delco pour l'armée de Terre (Ministere des Armees / DGA, juin 2026)
- Le ministère des Armées commande 5 000 drones DELCO supplémentaires auprès du français Harmattan AI (Opex360 / Zone Militaire, 23 juin 2026)
- Armer les drones et poursuivre son expansion, la double mission d'EURENCO (Forces Operations Blog, 9 juillet 2026)
- Eurosatory 2026: Helicopters and CUAS set to dominate as Europe advances rearmament efforts (Eurosatory, 2026)
- L'Ukraine a mis en évidence le besoin de drones et de contre-drones, mais pas uniquement... (Meta-Defense, 25 juin 2026)
- La technologie des drones évolue tous les 3 à 6 mois, obligeant l'Europe à acheter des systèmes en retard (Observatoire de l'Europe, 2026)

Koddex helps drone and defense system manufacturers iterate fast without losing control: requirements, configurations, incremental qualification and per-unit traceability in a single repository. Let's talk about your production rates.